# WP-Cron-erstatning

Queuety kan erstatte det indbyggede WordPress-cron-system. Når funktionen er aktiveret, opfanges kald til `wp_schedule_event()` og sendes gennem Queuetys scheduler i stedet for standardmekanismen WP-Cron. Hændelserne er beregnet til at blive behandlet af arbejderen Queuety, som kan udføre dem uafhængigt af trafikken på webstedet.

> **Aktuel begrænsning:** Broen opretter Queuety-planerne, men arbejderen har ingen handler til de `__queuety_cron_{hook}`-jobs, de producerer, så de oprindelige WordPress-callbacks bliver aldrig kørt. Hvert job fejler, forsøges igen efter en ventetid og begraves til sidst ([#9](https://github.com/inline0/queuety/issues/9)). Aktivér ikke broen på et websted, hvor cron-hændelser skal køres, før dette er rettet.

## Aktivér erstatningen

Kald `Queuety::replace_wp_cron()` tidligt i initialiseringen af dit plugin eller tema:

```php
use Queuety\Queuety;

Queuety::replace_wp_cron();
```

Dette kaldes typisk i pluginets hovedfil eller i et `plugins_loaded`-hook. Det skal kaldes, mens WordPress er indlæst (pluginnet skal være aktivt).

## Hvad den opfanger

cron-broen kobler sig på tre WordPress-filtre:

| WordPress-funktion | Tilkoblet filter | Adfærd |
|---|---|---|
| `wp_schedule_event()` | `pre_schedule_event` | Opretter en Queuety-plan med samme interval |
| `wp_unschedule_event()` | `pre_unschedule_event` | Fjerner den tilsvarende Queuety-plan |
| `wp_get_scheduled_event()` | `pre_get_scheduled_event` | Returnerer plandata fra Queuety |

Kun **gentagne** hændelser (dem med en egenskab `schedule` som `hourly`, `twicedaily`, `daily`) opfanges. Enkeltstående hændelser, der planlægges med `wp_schedule_single_event()`, opfanges ikke.

## Sådan tilknyttes hændelser

Når et plugin kalder `wp_schedule_event()`, slår Queuety plannavnet op via `wp_get_schedules()`, opretter en Queuety-plan med handlernavnet `__queuety_cron_{hook}` og gemmer det oprindelige WordPress-hooknavn og argumenterne i planens data.

Hensigten er, at arbejderen Queuety, der behandler det planlagte job, kalder `do_action()` med det oprindelige hooknavn og argumenterne, så de eksisterende WordPress-callbacks køres, mens Queuety styrer timingen. `CronBridge::process_cron_event()` implementerer dette kald, men intet kalder den endnu (se begrænsningen ovenfor). Planer evalueres desuden kun af en langkørende `wp queuety work`-proces cirka én gang i minuttet (se [Planlægning](https://queuety.inline0.dev/da/docs/features/scheduling)).

### Løsning af intervaller

Broen slår først plannavne op via `wp_get_schedules()` og bruger derefter de indbyggede standardværdier:

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

Brugerdefinerede planintervaller registreret via filteret `cron_schedules` understøttes, så længe `wp_get_schedules()` returnerer dem.

## Gendan WP-Cron

Sådan går du tilbage til standardsystemet WordPress cron:

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

Dette fjerner filter-hooks og lader WordPress håndtere cron-hændelser gennem sin indbyggede mekanisme igen. Bemærk, at `DISABLE_WP_CRON` defineres som `true`, når broen installeres, og ikke kan fjernes under kørsel. Derfor skal du muligvis fjerne konstanten fra `wp-config.php` eller genstarte processen.

## Hvornår skal den bruges

Erstatningen er mest nyttig, når dit websted har lav trafik, når du har brug for mere pålidelig timing end WP-Cron kan levere, eller når du allerede kører arbejdere med Queuety og ønsker, at cron-afvikling indgår i det samme driftssystem. Den er også nyttig, når centraliseret overvågning er vigtig, fordi cron-hændelser så vises i de samme logfiler og målinger som dit øvrige køarbejde.

## Begrænsninger

Der er nogle vigtige begrænsninger. En aktiv Queuety-arbejder er nødvendig, ellers køres de planlagte hændelser aldrig. Kun gentagne planer opfanges; enkeltstående hændelser oprettet med `wp_schedule_single_event()` forbliver uden for broen. `replace_wp_cron()` definerer også `DISABLE_WP_CRON` for resten af den aktuelle PHP-proces, så `restore_wp_cron()` fjerner hooks, men kan ikke fjerne konstanten. Endelig fungerer broen kun, når WordPress er indlæst, fordi den afhænger af filtrene WordPress og `do_action()`.

## Eksempel: fuld opsætning

```php
use Queuety\Queuety;

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

Her er det ikke nødvendigt at kalde `Queuety::init()`: det aktive Queuety-plugin opretter sin forbindelse ud fra WordPress-databaselegitimationsoplysningerne og initialiserer sig selv ved `plugins_loaded`. `replace_wp_cron()` installerer kun filtrene, så den er ikke afhængig af, at det er sket først.

Derefter gemmes gentagne hændelser, som plugins registrerer med `wp_schedule_event()`, som Queuety-planer. Indtil [#9](https://github.com/inline0/queuety/issues/9) er rettet, køres deres callbacks ikke.