CLI

QUIQQER packages can add console tools for maintenance tasks, imports, background operations, migrations, and support workflows.

Console tools are PHP classes registered through console.xml. They are loaded from installed packages and from projects, so a package can ship its own command without changing the application.

Register A Console Tool

Create console.xml in the package root and register one or more tool classes.

<?xml version="1.0" encoding="UTF-8"?>
<console>
    <tool exec="\Vendor\Package\Console\SendMail"/>
</console>

Use a fully qualified class name in the exec attribute. Keep the XML file small: it should only declare which classes are available as console tools.

Real package shape:

<?xml version="1.0" encoding="UTF-8"?>
<console>
    <tool exec="\QUI\Cron\Console\ExecCrons"/>
    <tool exec="\QUI\Cron\Console\AutoCreateCrons"/>
</console>

Implement A Tool Class

Console tool classes extend QUI\System\Console\Tool. Define the command name, description, arguments, and execution logic in the class.

<?php

namespace Vendor\Package\Console;

use QUI;

class SendMail extends QUI\System\Console\Tool
{
    public function __construct()
    {
        $this->setName('vendor-package:send-mail')
            ->setDescription('Send a package mail.')
            ->addArgument('id', 'Entity ID');
    }

    public function execute(): void
    {
        $id = $this->getArgument('id');

        // Run the package-specific operation here.
        $this->writeLn('Mail sent for ID ' . $id);
    }
}

Command names should be explicit and package-scoped. Use a clear prefix, for example package:cron, vendor-package:task-name, or vendor-package:rebuild-index.

Arguments

Use addArgument() for arguments that should appear in the command help.

$this->addArgument(
    'brickId',
    QUI::getLocale()->get('quiqqer/bricks', 'console.example.help.brickId')
);

Arguments are read with getArgument().

$brickId = $this->getArgument('brickId');

Shell Completion Metadata

Shell completion is available starting with QUIQQER 2.31.

Package commands participate in shell completion automatically. No additional entry in console.xml is required beyond the normal tool registration.

The tool metadata controls what operators see:

• setName() provides the completed command name.
• setDescription() provides the description in command listings and prefix suggestions.
• addArgument() provides long options and, when present, their short forms.

For example:

$this->setName('vendor-package:send-mail')
    ->setDescription('Send a package mail.')
    ->addArgument('id', 'Entity ID', 'i');

After the operator has installed completion, this metadata supports command and option completion such as:

./console vendor-package:<Tab><Tab>
./console vendor-package:send-mail --<Tab><Tab>

Command and option names are completed. Packages should not rely on completion for option values; document required values in the argument description and command help.

Do not use these names for custom arguments because they are reserved by the console runtime:

• help
• tool
• listtools
• u
• p
• username
• password

Localization

Package commands should use locale.xml for descriptions, argument help, and user-facing output. This keeps CLI messages translatable in the same way as backend and frontend text.

$this->setDescription(
    QUI::getLocale()->get('vendor/package', 'console.myTool.description')
);

Exit Behavior

A console tool should end with a successful process status when the operation completed and a failing process status when the operation cannot continue.

Use clear output before exiting:

$this->writeLn('No record found for the given ID.');
exit(1);

For expected business cases, print a short actionable message. For exceptions, log the exception and return a failing status.

Common Use Cases

Good package-level CLI tasks are:

• running scheduled package tasks
• importing or exporting package data
• repairing derived data after a deployment
• running package-specific cleanup jobs
• executing support tasks that should not be exposed in the backend

Do not put interactive backend workflows into console tools. A console tool should be safe to run from a shell and clear about its required arguments.

Developer Tooling

console.xml is for QUIQQER runtime commands. Composer scripts in composer.json are for repository development tasks such as linting, static analysis, PHPUnit, and git hook setup.

Use both where they fit:

• Put package operations for an installed QUIQQER system into console.xml.
• Put repository checks and setup commands into Composer scripts.