# Selbst-Registrierung > Wie andere Module ihre Jobs dem Cronjob-Modul anbieten --- Andere Module können ihre [geplanten Jobs](../cli-scripts) *anbieten*, damit sie in der Admin-UI erscheinen, ohne dass jemand die Registry manuell editiert. Dazu können zwei Wege beschritten werden (ein Modul kann beide verwenden) - beide werden automatisch bei jedem [Tick](../tick) entdeckt, wobei dies nur für **aktivierte** Module gilt: ## Marker-Methode `getCronJobs(): array` in der Modul-module.php -Klasse, die dasselbe Format zurückgibt. Entsprechend: `getModuleEvents(): array`, `getModuleCommands(): array`. ## Manifest-Datei (empfohlen) Bereitstellung einer Datei im Modulverzeichnis (`modules_v4//cron-jobs.php`), die ein Array von Job-Spezifikationen zurückgibt: 
<?php
// modules_v4/linkenhancer/cron-jobs.php
declare(strict_types=1);

return [
    [
        'name'         => 'link-index',
        'title'        => 'Update the link index',
        'triggers'     => [
            ['type' => 'time', 'cron' => '*/30 * * * *'],
        ],
        'command_type' => 'module',
        'command'      => 'modules_v4/linkenhancer/cli/build-link-index.php',
        'args'         => '--limit=5000',
    ],
];
Übersetzbare `title` / `description`-Texte in einem Manifest sollten in `MoreI18N::translate()` (Identitäts-Markierung) gesetzt werden, damit `xgettext` sie aufnimmt — die Übersetzung erfolgt zur Render-Zeit, nie beim laden des Manifests. ### Job-Spezifikations-Felder | Schlüssel | Erforderlich | Bedeutung | | :--- | :--- | :--- | | `name` | ja | Slug `a-z 0-9 _ -`, max. 64; gespeichert als `:` | | `title` | nein | menschlicher Name (Default = `name`) | | `triggers` | ja | Liste von Trigger-Einträgen, mindestens einer | | `command_type` | ja | `module` oder `core` | | `command` | ja | der Befehl | | `args` | nein | einfache Option/Wert-Tokens | | `enabled` | nein | Default `false` — entdeckte Jobs werden deaktiviert erstellt | | `timeout_sec` | nein | Default `300`, Bereich 30 - 3600 | Sobald ein entdeckter Job eingefügt ist, ist er unter **Admin-Kontrolle**: spätere Ticks überschreiben ihn nie. ## Ereignisse ankündigen Dasselbe Manifest kann auch [**Ereignisse**](../events) ankündigen, die das Modul auslöst (damit sie im Ereignis-Katalog und in den Vorschlägen des Job-Formulars erscheinen). Anstelle einer einfachen Job-Liste kann das Manifest ein assoziatives Array mit optionalen `jobs`- und `events`-Listen zurückgeben (eine einfache Liste bedeutet weiterhin „nur Jobs"): 
<?php
// modules_v4/linkenhancer/cron-jobs.php
declare(strict_types=1);

return [
    'jobs' => [
        [
            'name'     => 'link-index',
            'triggers' => [
                ['type' => 'time', 'cron' => '*/30 * * * *'],
                // A job may combine several triggers:
                // ['type' => 'event', 'event' => 'linkenhancer:index-dirty'],
            ],
            'command_type' => 'module',
            'command'      => 'modules_v4/linkenhancer/cli/build-link-index.php',
        ],
    ],
    'events' => [
        ['name' => 'index-dirty', 'description' => 'The link index is out of date.', 'payload' => ['tree']],
    ],
];
- Ein angekündigtes Ereignis ist namespaced **`:`** (wie die angebotenen Job-Schlüssel). - Der `event`-Wert eines Ereignis-Triggers, der keinen Doppelpunkt trägt, wird automatisch namespaced `:`; ein Name, der bereits einen Doppelpunkt hat (z.B. `cronjob:log-edit-update`), bleibt unverändert. - Entsprechende Marker-Methode: `getModuleEvents(): array` (dasselbe Event-Spec-Format). ### Event-Spezifikations-Felder | Schlüssel | Erforderlich | Bedeutung | | :--- | :--- | :--- | | `name` | ja | Slug `a-z 0-9 _ -` (gespeichert als `:`) | | `description` | nein | wird im Ereignis-Katalog angezeigt (Übersetzungsschlüssel, max. 255) | | `payload` | nein | Liste von Payload-Parameter-Namen (max. 8), wird im Katalog angezeigt | ## Befehle ankündigen Dasselbe Manifest kann auch **Befehle** ankündigen, die ein Job ausführen kann, mit ihren verfügbaren Parametern. Eine einfache Manifest-Liste bedeutet weiterhin „nur Jobs"; um Befehle anzukündigen, gibt das Manifest die assoziative Form mit einer `commands`-Liste zurück: 
// modules_v4/linkenhancer/cron-jobs.php
declare(strict_types=1);

return [
    'jobs' => [ /* … */ ],
    'commands' => [
        [
            'command'      => 'modules_v4/linkenhancer/cli/build-link-index.php',
            // 'command_type' => 'module',  // optional - derived from the command value
            'description'  => 'Rebuild the link index incrementally.',
            'params' => [
                ['name' => '--limit', 'optional' => true, 'default' => '5000', 'description' => 'max records per run'],
                ['name' => '--since', 'optional' => true, 'description' => 'only changes since this timestamp'],
            ],
        ],
    ],
];
### Command-Spezifikations-Felder | Schlüssel | Erforderlich | Bedeutung | | :--- | :--- | :--- | | `command` | ja | ein `modules_v4/…/cli/*.php`-Pfad oder ein erlaubter Core-Befehl, max. 255 | | `command_type` | nein | `module` oder `core` (wird bei weggelassenem Wert aus `command` abgeleitet) | | `description` | nein | wird im Befehl-Katalog angezeigt (Übersetzungsschlüssel, max. 255) | | `params` | nein | Liste von Parameter-Deskriptoren (max. 8) | Jeder Parameter-Deskriptor hat `name` (das Option-Token, z.B. `--limit`), `optional` (Bool, Default `true` — auf `false` setzen für eine erforderliche Option), `default` (ein optionaler Wert) und `description` (optional). Entsprechende Marker-Methode: `getModuleCommands(): array` (dasselbe Command-Spec-Format). > **Kurations-Regel:** Ein Modul, das Befehle ankündigt, **kuratiert seine eigene Befehlsliste** — > die glob-basierte Entdeckung listet *seine* Skripte nicht mehr auf, sodass interne Skripte > (tick.php , watch.php , wrap.php , smoke-job.php ) nicht als Job-Befehle angeboten > werden. Ein Modul, das nichts ankündigt, fällt auf die glob-Entdeckung seiner > `cli/`-Skripte zurück (abwärtskompatibel).