# Înlocuire WP-Cron

Queuety poate înlocui sistemul WordPress cron integrat. Când este activată, apelurile către `wp_schedule_event()` sunt interceptate și direcționate prin programatorul Queuety în locul mecanismului implicit WP-Cron. Evenimentele sunt procesate de lucrătorul Queuety, care execută independent de traficul site-ului.

> **Limitare actuală:** puntea creează programările Queuety, însă lucrătorul nu are un handler pentru joburile `__queuety_cron_{hook}` pe care acestea le generează, așa că apelurile originale WordPress nu se execută niciodată. Fiecare job eșuează, este reîncercat cu o întârziere progresivă și, în cele din urmă, este îngropat ([#9](https://github.com/inline0/queuety/issues/9)). Nu activați puntea pe un site ale cărui evenimente cron trebuie să ruleze până când problema este remediată.

## Activarea înlocuirii

Apelați `Queuety::replace_wp_cron()` la începutul inițializării pluginului sau temei:

```php
use Queuety\Queuety;

Queuety::replace_wp_cron();
```

De obicei, se apelează în fișierul principal al pluginului sau într-un hook `plugins_loaded`. Apelul trebuie făcut când WordPress este încărcat (pluginul trebuie să fie activ).

## Ce interceptează

Puntea cron se conectează la trei filtre WordPress:

| Funcția WordPress | Filtru conectat | Comportament |
|---|---|---|
| `wp_schedule_event()` | `pre_schedule_event` | Creează o programare Queuety cu același interval |
| `wp_unschedule_event()` | `pre_unschedule_event` | Elimină programarea Queuety corespunzătoare |
| `wp_get_scheduled_event()` | `pre_get_scheduled_event` | Returnează datele programării din Queuety |

Sunt interceptate doar evenimentele **recurente** (cele cu o proprietate `schedule` precum `hourly`, `twicedaily`, `daily`). Evenimentele unice, programate cu `wp_schedule_single_event()`, nu sunt interceptate.

## Cum sunt mapate evenimentele

Când un plugin apelează `wp_schedule_event()`, Queuety identifică numele programării prin `wp_get_schedules()`, creează o programare Queuety cu numele handlerului `__queuety_cron_{hook}` și stochează numele hookului original WordPress și argumentele în datele programării.

Comportamentul dorit este ca lucrătorul Queuety care procesează jobul programat să apeleze `do_action()` cu numele hookului original și argumentele, astfel încât apelurile existente WordPress să ruleze, iar Queuety să controleze temporizarea. `CronBridge::process_cron_event()` implementează acel apel, dar momentan nimic nu îl invocă (consultați limitarea de mai sus). Programările sunt evaluate doar de un proces `wp queuety work` de lungă durată, aproximativ o dată pe minut (consultați [Planificare](https://queuety.inline0.dev/ro/docs/features/scheduling)).

### Determinarea intervalului

Puntea identifică mai întâi numele programărilor prin `wp_get_schedules()`, apoi folosește valorile implicite integrate:

| Numele programării | Interval |
|---|---|
| `hourly` | 3,600 secunde |
| `twicedaily` | 43,200 secunde |
| `daily` | 86,400 secunde |
| `weekly` | 604,800 secunde |

Intervalele personalizate ale programărilor, înregistrate prin filtrul `cron_schedules`, sunt acceptate dacă `wp_get_schedules()` le returnează.

## Restabilirea WP-Cron

Pentru a reveni la sistemul implicit WordPress cron:

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

Astfel se elimină hookurile de filtrare și WordPress poate gestiona din nou evenimentele cron prin mecanismul integrat. Rețineți că `DISABLE_WP_CRON` este definită ca `true` la instalarea punții și nu poate fi anulată în timpul execuției, așadar poate fi necesar să eliminați constanta respectivă din `wp-config.php` sau să reporniți procesul.

## Când să îl folosiți

Înlocuirea este utilă mai ales când site-ul are trafic redus, când aveți nevoie de o temporizare mai fiabilă decât cea oferită de WP-Cron sau când rulați deja lucrători Queuety și doriți ca execuția cron să facă parte din același sistem operațional. Este utilă și când observabilitatea centralizată contează, deoarece evenimentele cron apar atunci în aceleași jurnale și metrice ca celelalte activități din coadă.

## Limitări

Există câteva constrângeri importante. Este necesar un lucrător Queuety activ, altfel evenimentele programate nu vor rula niciodată. Sunt interceptate doar programările recurente; evenimentele unice create cu `wp_schedule_single_event()` rămân în afara punții. `replace_wp_cron()` definește și `DISABLE_WP_CRON` pentru restul procesului PHP curent, așadar `restore_wp_cron()` elimină hookurile, dar nu poate anula definiția constantei. În cele din urmă, puntea funcționează doar când WordPress este încărcat, deoarece depinde de filtrele WordPress și de `do_action()`.

## Exemplu: configurare completă

```php
use Queuety\Queuety;

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

Nu este nevoie să apelați `Queuety::init()` aici: pluginul Queuety activ își construiește conexiunea din datele de autentificare ale bazei de date WordPress și se inițializează la `plugins_loaded`. `replace_wp_cron()` doar instalează filtrele, deci nu depinde de finalizarea acestui pas în prealabil.

După aceea, evenimentele recurente pe care pluginurile le înregistrează cu `wp_schedule_event()` sunt stocate ca programări Queuety. Până la remedierea [#9](https://github.com/inline0/queuety/issues/9), apelurile lor de revenire nu se execută.