Zum Inhalt springen

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). 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).

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 behoben ist, werden ihre Callbacks nicht ausgeführt.