# 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](https://github.com/inline0/queuety/issues/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:

```php
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:

| WordPress-functie | Ingehaakt filter | Werking |
|---|---|---|
| `wp_schedule_event()` | `pre_schedule_event` | Maakt een Queuety-schema aan met hetzelfde interval |
| `wp_unschedule_event()` | `pre_unschedule_event` | Verwijdert het bijbehorende Queuety-schema |
| `wp_get_scheduled_event()` | `pre_get_scheduled_event` | Geeft schemagegevens uit Queuety terug |

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](https://queuety.inline0.dev/nl/docs/features/scheduling)).

### Interval bepalen

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

| Schemanaam | Interval |
|---|---|
| `hourly` | 3,600 seconden |
| `twicedaily` | 43,200 seconden |
| `daily` | 86,400 seconden |
| `weekly` | 604,800 seconden |

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:

```php
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

```php
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](https://github.com/inline0/queuety/issues/9) niet is opgelost, worden de bijbehorende callbacks niet uitgevoerd.