Sur une installation locale sans trafic, le pseudo-cron de WordPress ne se déclenche jamais tout seul : il dépend d’une requête HTTP entrante pour vérifier si des tâches sont dues. Sans visiteur ni robot d’indexation, une tâche planifiée peut rester en attente indéfiniment, ce qui complique le test d’une fonctionnalité qui en dépend.
Plutôt que de modifier l’horloge système ou de rafraîchir frénétiquement une page en espérant déclencher le mécanisme, la fonction interne spawn_cron() permet de forcer une vérification immédiate depuis un script exécuté manuellement.
Comment fonctionne le pseudo-cron
À chaque chargement de page front-end, WordPress vérifie s’il existe des événements cron dont l’horodatage est dépassé. Si c’est le cas, il déclenche une requête HTTP interne vers wp-cron.php, généralement de façon non bloquante, pour exécuter les tâches dues sans ralentir la réponse envoyée au visiteur.
Ce mécanisme repose entièrement sur le trafic réel du site. Un environnement de développement sans visite ne génère jamais cette requête interne, et les tâches planifiées restent simplement en attente.
Utiliser spawn_cron() pour forcer le déclenchement
<?php
require_once '/chemin/vers/wp-load.php';
if ( function_exists( 'spawn_cron' ) ) {
spawn_cron();
echo "Vérification cron déclenchée.\n";
}
Ce script, exécuté depuis la ligne de commande PHP en environnement local, provoque la même vérification que celle normalement déclenchée par une visite. Les tâches dues s’exécutent alors immédiatement, sans attendre un trafic qui n’existe pas encore sur un site en construction.
Une alternative recommandée : WP-CLI
Pour un usage régulier plutôt que ponctuel, WP-CLI propose une commande dédiée, plus lisible qu’un script maison :
wp cron event run --due-now
wp cron event list
La première commande exécute immédiatement tous les événements dont l’horaire est passé, la seconde liste les événements programmés avec leur prochaine échéance. Ces deux commandes couvrent la plupart des besoins de débogage cron sans avoir à écrire de script personnalisé.
Ce que spawn_cron() ne fait pas
- Elle ne modifie ni n’avance l’horloge système du serveur : les événements futurs restent programmés à leur horaire réel.
- Elle ne remplace pas un vrai cron serveur configuré avec
DISABLE_WP_CRONàtrue: dans ce cas, c’est une tâche système externe qui doit appelerwp-cron.phpà intervalle régulier. - Elle reste soumise au même mécanisme de verrouillage que le pseudo-cron normal, évitant les exécutions concurrentes du même lot d’événements.
Un usage à réserver au développement
Appeler spawn_cron() directement dans du code de production n’a pas de sens : le mécanisme se déclenche déjà naturellement à chaque visite suffisamment espacée. Son intérêt se limite à des scripts de développement, des tests automatisés ou des environnements sans trafic réel.
Un repère pratique : dès qu’une tâche planifiée doit être testée en local sans attendre un trafic réaliste, la commande WP-CLI
wp cron event run --due-nowest presque toujours plus simple à retenir qu’un script d’appel àspawn_cron().
En résumé
Le pseudo-cron de WordPress dépend du trafic pour se déclencher, ce qui complique son test en environnement local silencieux. spawn_cron() et la commande WP-CLI équivalente permettent de forcer cette vérification sans manipuler l’horloge système, un réflexe utile dès qu’une tâche planifiée doit être validée avant sa mise en production.
