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');

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.