Aller au contenu

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). 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).

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 n’est pas corrigé, leurs rappels ne sont pas exécutés.