# Ersättning av WP-Cron

Queuety kan ersätta det inbyggda systemet WordPress cron. När funktionen är aktiverad fångas anrop till `wp_schedule_event()` upp och skickas via schemaläggaren i Queuety i stället för standardmekanismen WP-Cron. Händelserna är avsedda att behandlas av arbetaren Queuety, som kör oberoende av webbplatstrafiken.

> **Aktuell begränsning:** bryggan skapar Queuety-scheman, men arbetaren saknar en hanterare för de `__queuety_cron_{hook}`-jobb som de genererar, så de ursprungliga WordPress-återanropen körs aldrig. Varje jobb misslyckas, försöks igen med exponentiell fördröjning och begravs till slut ([#9](https://github.com/inline0/queuety/issues/9)). Aktivera inte bryggan på en webbplats där cron-händelser måste köras förrän detta är åtgärdat.

## Aktivera ersättningen

Anropa `Queuety::replace_wp_cron()` tidigt under initieringen av ditt plugin eller tema:

```php
use Queuety\Queuety;

Queuety::replace_wp_cron();
```

Detta anropas vanligtvis i pluginets huvudfil eller i en `plugins_loaded`-hook. Det måste anropas när WordPress har laddats (pluginet måste vara aktivt).

## Vad som fångas upp

Bryggan cron kopplar in sig på tre WordPress-filter:

| WordPress-funktion | Anslutet filter | Beteende |
|---|---|---|
| `wp_schedule_event()` | `pre_schedule_event` | Skapar ett schema för Queuety med samma intervall |
| `wp_unschedule_event()` | `pre_unschedule_event` | Tar bort motsvarande schema för Queuety |
| `wp_get_scheduled_event()` | `pre_get_scheduled_event` | Returnerar schemadata från Queuety |

Endast **återkommande** händelser (de som har egenskapen `schedule`, som `hourly`, `twicedaily` och `daily`) fångas upp. Engångshändelser som schemaläggs med `wp_schedule_single_event()` fångas inte upp.

## Så mappas händelser

När ett plugin anropar `wp_schedule_event()` löser Queuety schemanamnet via `wp_get_schedules()`, skapar ett schema för Queuety med hanterarnamnet `__queuety_cron_{hook}` och sparar det ursprungliga WordPress-hooknamnet och argumenten i schemats nyttolast.

Avsikten är att arbetaren Queuety som behandlar det schemalagda jobbet ska anropa `do_action()` med det ursprungliga hooknamnet och argumenten, så att de befintliga återanropen för WordPress körs med Queuety som styr tidpunkten. `CronBridge::process_cron_event()` implementerar anropet, men inget anropar det ännu (se begränsningen ovan). Scheman utvärderas dessutom bara av en långlivad `wp queuety work`-process ungefär en gång i minuten (se [Schemaläggning](https://queuety.inline0.dev/sv/docs/features/scheduling)).

### Intervallbestämning

Bryggan slår först upp schemanamn via `wp_get_schedules()` och använder sedan de inbyggda standardvärdena:

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

Anpassade schemaintervall som registreras via filtret `cron_schedules` stöds om `wp_get_schedules()` returnerar dem.

## Återställa WP-Cron

Så här återgår du till standardsystemet WordPress cron:

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

Detta tar bort filterhookarna och gör att WordPress åter kan hantera händelser för cron med sin inbyggda mekanism. Observera att `DISABLE_WP_CRON` definieras som `true` när bryggan installeras och inte kan avdefinieras under körning. Du kan därför behöva ta bort konstanten från `wp-config.php` eller starta om processen.

## När du ska använda det

Ersättningen är mest användbar när webbplatsen har låg trafik, när du behöver mer tillförlitlig schemaläggning än WP-Cron kan erbjuda eller när du redan kör arbetare Queuety och vill att körningen av cron ska ingå i samma driftssystem. Den underlättar också centraliserad övervakning, eftersom händelser för cron då visas i samma loggar och mätvärden som övriga köjobb.

## Begränsningar

Det finns några viktiga begränsningar. En aktiv arbetare Queuety krävs, annars körs de schemalagda händelserna aldrig. Endast återkommande scheman fångas upp; engångshändelser som skapas med `wp_schedule_single_event()` ligger fortfarande utanför bryggan. `replace_wp_cron()` definierar också `DISABLE_WP_CRON` för resten av den aktuella PHP-processen, så `restore_wp_cron()` tar bort hookarna men kan inte avdefiniera konstanten. Slutligen fungerar bryggan bara när WordPress är laddat, eftersom den är beroende av WordPress-filter och `do_action()`.

## Exempel: fullständig konfiguration

```php
use Queuety\Queuety;

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

Du behöver inte anropa `Queuety::init()` här: det aktiva pluginet Queuety skapar sin anslutning från databasuppgifterna WordPress och initierar sig självt vid `plugins_loaded`. `replace_wp_cron()` installerar bara filtren, så det kräver inte att detta har skett först.

Därefter lagras återkommande händelser som plugin registrerar med `wp_schedule_event()` som scheman för Queuety. Deras återanrop körs inte förrän [#9](https://github.com/inline0/queuety/issues/9) har åtgärdats.