# Remplacement de WP-Cron

Queuety peut remplacer le système WordPress cron intégré. Une fois activé, les appels à `wp_schedule_event()` sont interceptés et redirigés vers le planificateur de Queuety au lieu du mécanisme WP-Cron par défaut. Les événements doivent être traités par le worker Queuety, qui exécute les tâches indépendamment du trafic du site.

> **Limitation actuelle :** le pont crée les planifications Queuety, mais le worker ne dispose d’aucun gestionnaire pour les tâches `__queuety_cron_{hook}` qu’elles produisent ; les rappels WordPress d’origine ne sont donc jamais exécutés. Chaque tâche échoue, fait l’objet de nouvelles tentatives avec temporisation, puis finit par être mise en attente ([#9](https://github.com/inline0/queuety/issues/9)). N’activez pas le pont sur un site où les événements cron doivent être exécutés tant que ce problème n’est pas résolu.

## Activer le remplacement

Appelez `Queuety::replace_wp_cron()` au début de l’initialisation de votre extension ou de votre thème :

```php
use Queuety\Queuety;

Queuety::replace_wp_cron();
```

Cet appel est généralement placé dans le fichier principal de votre extension ou dans un hook `plugins_loaded`. Il doit avoir lieu lorsque WordPress est chargé (l’extension doit être activée).

## Éléments interceptés

Le pont cron utilise trois filtres WordPress :

| Fonction WordPress | Filtre utilisé | Comportement |
|---|---|---|
| `wp_schedule_event()` | `pre_schedule_event` | Crée une planification Queuety avec le même intervalle |
| `wp_unschedule_event()` | `pre_unschedule_event` | Supprime la planification Queuety correspondante |
| `wp_get_scheduled_event()` | `pre_get_scheduled_event` | Renvoie les données de planification de Queuety |

Seuls les événements **récurrents** (ceux qui ont une propriété `schedule` telle que `hourly`, `twicedaily` ou `daily`) sont interceptés. Les événements ponctuels planifiés avec `wp_schedule_single_event()` ne le sont pas.

## Correspondance des événements

Lorsqu’une extension appelle `wp_schedule_event()`, Queuety résout le nom de la planification via `wp_get_schedules()`, crée une planification Queuety avec le nom du gestionnaire `__queuety_cron_{hook}`, puis stocke le nom du hook WordPress d’origine et ses arguments dans les données de la planification.

Le comportement prévu est que le worker Queuety chargé de traiter la tâche planifiée appelle `do_action()` avec le nom du hook et les arguments d’origine, afin que les rappels WordPress existants s’exécutent, Queuety se chargeant de la planification. `CronBridge::process_cron_event()` implémente cet appel, mais rien ne l’invoque pour l’instant (voir la limitation ci-dessus). Les planifications sont également évaluées uniquement par un processus `wp queuety work` de longue durée, environ une fois par minute (voir [Planification](https://queuety.inline0.dev/fr/docs/features/scheduling)).

### Résolution des intervalles

Le pont commence par résoudre les noms de planification via `wp_get_schedules()`, puis utilise les valeurs intégrées par défaut :

| Nom de la planification | Intervalle |
|---|---|
| `hourly` | 3,600 secondes |
| `twicedaily` | 43,200 secondes |
| `daily` | 86,400 secondes |
| `weekly` | 604,800 secondes |

Les intervalles personnalisés enregistrés via le filtre `cron_schedules` sont pris en charge à condition que `wp_get_schedules()` les renvoie.

## Rétablir WP-Cron

Pour revenir au système WordPress cron par défaut :

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

Cela supprime les hooks de filtre et permet à WordPress de traiter à nouveau les événements cron avec son mécanisme intégré. Notez que `DISABLE_WP_CRON` est défini sur `true` lors de l’installation du pont et ne peut pas être supprimé à l’exécution ; vous devrez peut-être retirer cette constante de `wp-config.php` ou redémarrer le processus.

## Quand l’utiliser

Ce remplacement est particulièrement utile lorsque votre site reçoit peu de trafic, que vous avez besoin d’une planification plus fiable que celle que peut fournir WP-Cron, ou que vous exécutez déjà des workers Queuety et souhaitez intégrer l’exécution cron au même système opérationnel. Il facilite aussi la supervision centralisée : les événements cron apparaissent alors dans les mêmes journaux et les mêmes métriques que les autres tâches de la file.

## Limites

Il y a quelques contraintes importantes. Un worker Queuety actif est nécessaire ; sinon, les événements planifiés ne seront jamais exécutés. Seules les planifications récurrentes sont interceptées ; les événements ponctuels créés avec `wp_schedule_single_event()` restent hors du pont. `replace_wp_cron()` définit également `DISABLE_WP_CRON` pour le reste du processus PHP en cours : `restore_wp_cron()` supprime donc les hooks, mais ne peut pas supprimer la constante. Enfin, le pont ne fonctionne que si WordPress est chargé, car il dépend des filtres WordPress et de `do_action()`.

## Exemple : configuration complète

```php
use Queuety\Queuety;

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

Il n’est pas nécessaire d’appeler `Queuety::init()` ici : l’extension Queuety active établit sa connexion à partir des identifiants de base de données WordPress et s’initialise sur `plugins_loaded`. `replace_wp_cron()` installe uniquement les filtres ; son fonctionnement ne dépend donc pas de l’initialisation préalable de l’extension.

À partir de là, les événements récurrents enregistrés par les extensions avec `wp_schedule_event()` sont stockés comme planifications Queuety. Tant que [#9](https://github.com/inline0/queuety/issues/9) n’est pas corrigé, leurs rappels ne sont pas exécutés.