# WP-Cron ersetzen

Queuety kann das integrierte WordPress-cron-System ersetzen. Nach der Aktivierung werden Aufrufe von `wp_schedule_event()` abgefangen und über den Scheduler von Queuety statt über den standardmäßigen WP-Cron-Mechanismus ausgeführt. Die Ereignisse werden vom Worker Queuety verarbeitet, der die Ausführung unabhängig vom Website-Traffic ermöglicht.

> **Aktuelle Einschränkung:** Die Bridge erstellt die Queuety-Zeitpläne, aber dem Worker fehlt ein Handler für die `__queuety_cron_{hook}`-Jobs, die sie erzeugen, sodass die ursprünglichen WordPress-Callbacks nie ausgeführt werden. Jeder Job schlägt fehl, wird mit zunehmenden Wartezeiten erneut versucht und schließlich in den Papierkorb verschoben ([#9](https://github.com/inline0/queuety/issues/9)). Aktiviere die Bridge nicht auf einer Website, auf der cron-Ereignisse ausgeführt werden müssen, bis das behoben ist.

## Ersatz aktivieren

Rufe `Queuety::replace_wp_cron()` früh während der Initialisierung deines Plugins oder Themes auf:

```php
use Queuety\Queuety;

Queuety::replace_wp_cron();
```

Das geschieht üblicherweise in der Hauptdatei deines Plugins oder in einem `plugins_loaded`-Hook. Der Aufruf muss erfolgen, während WordPress geladen ist (das Plugin muss aktiv sein).

## Was abgefangen wird

Die cron-Bridge hängt sich in drei WordPress-Filter ein:

| WordPress-Funktion | Eingebundener Filter | Verhalten |
|---|---|---|
| `wp_schedule_event()` | `pre_schedule_event` | Erstellt einen Queuety-Zeitplan mit demselben Intervall |
| `wp_unschedule_event()` | `pre_unschedule_event` | Entfernt den entsprechenden Queuety-Zeitplan |
| `wp_get_scheduled_event()` | `pre_get_scheduled_event` | Gibt Zeitplandaten von Queuety zurück |

Abgefangen werden nur **wiederkehrende** Ereignisse, also solche mit einer Eigenschaft `schedule` wie `hourly`, `twicedaily` oder `daily`. Einmalige Ereignisse, die mit `wp_schedule_single_event()` geplant werden, werden nicht abgefangen.

## Zuordnung von Ereignissen

Wenn ein Plugin `wp_schedule_event()` aufruft, ermittelt Queuety den Zeitplannamen über `wp_get_schedules()`, erstellt einen Queuety-Zeitplan mit dem Handler-Namen `__queuety_cron_{hook}` und speichert den ursprünglichen WordPress-Hook-Namen und die Argumente in der Zeitplan-Nutzlast.

Vorgesehen ist, dass der Worker Queuety, der diesen geplanten Job verarbeitet, `do_action()` mit dem ursprünglichen Hook-Namen und den Argumenten aufruft, damit die bestehenden WordPress-Callbacks ausgeführt werden und Queuety den Zeitpunkt steuert. `CronBridge::process_cron_event()` implementiert diesen Aufruf, aber noch nichts führt ihn aus (siehe Einschränkung oben). Zeitpläne werden außerdem nur von einem `wp queuety work`-Prozess mit langer Laufzeit ausgewertet, etwa einmal pro Minute (siehe [Zeitplanung](https://queuety.inline0.dev/de/docs/features/scheduling)).

### Intervall ermitteln

Die Bridge ermittelt Zeitplannamen zunächst über `wp_get_schedules()` und greift dann auf integrierte Standardwerte zurück:

| Zeitplanname | Intervall |
|---|---|
| `hourly` | 3,600 Sekunden |
| `twicedaily` | 43,200 Sekunden |
| `daily` | 86,400 Sekunden |
| `weekly` | 604,800 Sekunden |

Benutzerdefinierte Zeitplanintervalle, die über den Filter `cron_schedules` registriert werden, werden unterstützt, sofern `wp_get_schedules()` sie zurückgibt.

## WP-Cron wiederherstellen

So kehrst du zum standardmäßigen System WordPress-cron zurück:

```php
Queuety::restore_wp_cron();
```

Dadurch werden die Filter-Hooks entfernt und WordPress kann cron-Ereignisse wieder über seinen integrierten Mechanismus verarbeiten. Beachte, dass `DISABLE_WP_CRON` bei der Installation der Bridge als `true` definiert wird und sich zur Laufzeit nicht wieder löschen lässt. Du musst diese Konstante daher möglicherweise aus `wp-config.php` entfernen oder den Prozess neu starten.

## Wann du ihn verwenden solltest

Der Ersatz ist besonders nützlich, wenn deine Website wenig Traffic hat, du eine zuverlässigere Zeitplanung als mit WP-Cron brauchst oder bereits Queuety-Worker ausführst und die Ausführung von cron in dasselbe Betriebssystem integrieren möchtest. Er hilft auch bei zentraler Beobachtbarkeit, da cron-Ereignisse dann in denselben Protokollen und Metriken wie deine anderen Warteschlangenjobs erscheinen.

## Einschränkungen

Es gibt einige wichtige Einschränkungen. Ein aktiver Queuety-Worker ist erforderlich, sonst werden die geplanten Ereignisse nie ausgeführt. Abgefangen werden nur wiederkehrende Zeitpläne; einmalige Ereignisse, die mit `wp_schedule_single_event()` erstellt wurden, bleiben außerhalb der Bridge. `replace_wp_cron()` definiert außerdem `DISABLE_WP_CRON` für den Rest des aktuellen PHP-Prozesses. Daher entfernt `restore_wp_cron()` zwar die Hooks, kann die Konstante aber nicht löschen. Schließlich funktioniert die Bridge nur, wenn WordPress geladen ist, da sie von WordPress-Filtern und `do_action()` abhängt.

## Beispiel: vollständige Einrichtung

```php
use Queuety\Queuety;

// In your plugin's main file.
add_action( 'plugins_loaded', function () {
    Queuety::replace_wp_cron();
} );
```

Hier musst du `Queuety::init()` nicht aufrufen: Das aktive Plugin Queuety stellt seine Verbindung anhand der Datenbank-Zugangsdaten von WordPress her und initialisiert sich bei `plugins_loaded`. `replace_wp_cron()` installiert nur die Filter und setzt daher nicht voraus, dass das zuvor geschehen ist.

Danach werden wiederkehrende Ereignisse, die Plugins mit `wp_schedule_event()` registrieren, als Queuety-Zeitpläne gespeichert. Bis [#9](https://github.com/inline0/queuety/issues/9) behoben ist, werden ihre Callbacks nicht ausgeführt.