WP-Cron vervangen

Queuety kan het ingebouwde WordPress-cronsysteem vervangen. Wanneer dit is ingeschakeld, worden aanroepen naar wp_schedule_event() onderschept en via de planner van Queuety geleid, in plaats van via het standaardmechanisme van WP-Cron. Gebeurtenissen worden verwerkt door de worker van Queuety, die uitvoering onafhankelijk van siteverkeer mogelijk maakt.

Huidige beperking: de bridge maakt de Queuety-schema's aan, maar de worker heeft geen handler voor de __queuety_cron_{hook}-taken die ze opleveren, waardoor de oorspronkelijke callbacks van WordPress nooit worden uitgevoerd. Elke taak mislukt, wordt opnieuw geprobeerd met een oplopende wachttijd en belandt uiteindelijk in de archiefwachtrij (#9). Schakel de bridge niet in op een site waar cron-gebeurtenissen moeten worden uitgevoerd zolang dit niet is opgelost.

De vervanging inschakelen

Roep Queuety::replace_wp_cron() vroeg aan tijdens de initialisatie van uw plugin of thema:

use Queuety\Queuety;

Queuety::replace_wp_cron();

Dit wordt doorgaans aangeroepen in het hoofdbestand van uw plugin of in een plugins_loaded-hook. Dit moet gebeuren wanneer WordPress is geladen (de plugin moet actief zijn).

Wat wordt onderschept

De cron-bridge haakt in op drie WordPress-filters:

Alleen terugkerende gebeurtenissen (met een eigenschap schedule zoals hourly, twicedaily of daily) worden onderschept. Eenmalige gebeurtenissen die met wp_schedule_single_event() worden ingepland, worden niet onderschept.

Hoe gebeurtenissen worden gekoppeld

Wanneer een plugin wp_schedule_event() aanroept, bepaalt Queuety de schemanaam via wp_get_schedules(), maakt het een Queuety-schema aan met de handlernaam __queuety_cron_{hook} en slaat het de oorspronkelijke WordPress-hooknaam en argumenten op in de schema-payload.

De bedoeling is dat de Queuety-worker die de ingeplande taak verwerkt do_action() aanroept met de oorspronkelijke hooknaam en argumenten, zodat de bestaande callbacks van WordPress worden uitgevoerd en Queuety de timing bepaalt. CronBridge::process_cron_event() implementeert die aanroep, maar er wordt nog niets aangeroepen (zie de beperking hierboven). Schema's worden bovendien alleen geëvalueerd door een langlopend wp queuety work-proces, ongeveer één keer per minuut (zie Planning).

Interval bepalen

De bridge bepaalt eerst de schemanaam via wp_get_schedules() en valt daarna terug op ingebouwde standaardwaarden:

Aangepaste schema-intervallen die via het cron_schedules-filter zijn geregistreerd, worden ondersteund zolang wp_get_schedules() ze teruggeeft.

WP-Cron herstellen

Ga als volgt terug naar het standaard WordPress-cronsysteem:

Queuety::restore_wp_cron();

Hiermee verwijdert u de filterhooks en kan WordPress gebeurtenissen van cron weer via het ingebouwde mechanisme afhandelen. Houd er rekening mee dat DISABLE_WP_CRON als true wordt gedefinieerd wanneer de bridge wordt geïnstalleerd en tijdens runtime niet ongedefinieerd kan worden. Mogelijk moet u die constante daarom uit wp-config.php verwijderen of het proces opnieuw starten.

Wanneer gebruik je deze?

De vervanging is vooral nuttig wanneer uw site weinig verkeer heeft, wanneer u betrouwbaardere timing nodig hebt dan WP-Cron kan bieden, of wanneer u al Queuety-workers uitvoert en cron-uitvoering in hetzelfde operationele systeem wilt onderbrengen. Het helpt ook wanneer gecentraliseerde observatie belangrijk is, omdat gebeurtenissen van cron dan in dezelfde logs en statistieken verschijnen als uw andere wachtrijwerk.

Beperkingen

Er zijn enkele belangrijke beperkingen. Er is een actieve Queuety-worker vereist; anders worden de ingeplande gebeurtenissen nooit uitgevoerd. Alleen terugkerende schema's worden onderschept; eenmalige gebeurtenissen die met wp_schedule_single_event() zijn aangemaakt, blijven buiten de bridge. replace_wp_cron() definieert DISABLE_WP_CRON ook voor de rest van het huidige PHP-proces. restore_wp_cron() verwijdert dus wel de hooks, maar kan de constante niet ongedefinieerd maken. Tot slot werkt de bridge alleen wanneer WordPress is geladen, omdat deze afhankelijk is van WordPress-filters en do_action().

Voorbeeld: volledige configuratie

use Queuety\Queuety;

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

U hoeft hier Queuety::init() niet aan te roepen: de actieve plugin Queuety maakt verbinding met de inloggegevens van de WordPress-database en initialiseert zichzelf bij plugins_loaded. replace_wp_cron() installeert alleen de filters en is daarom niet afhankelijk van die voorafgaande stap.

Daarna worden terugkerende gebeurtenissen die plugins met wp_schedule_event() registreren, opgeslagen als Queuety-schema's. Zolang #9 niet is opgelost, worden de bijbehorende callbacks niet uitgevoerd.