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