Le WordPress d'aujourd'hui, décodé pour les développeurs

Hébergement & serveurs

DISABLE_WP_CRON et un vrai cron système pour un trafic irrégulier

Des articles programmés qui ne se publient plus à l'heure prévue : le faux cron de WordPress trahit un trafic devenu trop irrégulier pour le déclencher.

Par WordPress Développement • 3 mars 2020 • 4 min de lecture • Aucun commentaire
DISABLE_WP_CRON et un vrai cron système pour un trafic irrégulier

wp cron event list : cette simple commande WP-CLI a suffi à confirmer ce qu’un développeur soupçonnait déjà. Plusieurs tâches planifiées, dont la publication d’articles programmés et le nettoyage des révisions, affichaient un statut « en retard » de plusieurs heures, certaines de plus d’une demi-journée.

Le site en question n’a rien d’inhabituel : un blog associatif dont le trafic se concentre presque entièrement en soirée, avec des heures creuses quasi désertes le reste de la journée. C’est précisément ce profil de trafic irrégulier qui met en évidence un mécanisme souvent mal compris de WordPress : WP-Cron ne fonctionne pas comme un vrai cron système.

Comprendre pourquoi WP-Cron s’est arrêté de fonctionner

Par défaut, WordPress ne dispose d’aucun processus planifié indépendant. Le fichier wp-cron.php est appelé à chaque chargement de page côté visiteur, ce qui déclenche une vérification des tâches en attente. Tant qu’il y a du trafic régulier, ce système fonctionne de manière à peu près satisfaisante, malgré son imprécision.

  • Aucune visite entre minuit et 6 heures du matin
  • Un article programmé à 5 h ne se publie qu’à la première visite suivante, parfois vers 9 h
  • Le nettoyage périodique des transients et des révisions s’exécute très irrégulièrement

Mettre en place un vrai cron système

La solution consiste à désactiver le déclenchement implicite via le trafic, puis à confier l’appel de wp-cron.php à un cron système classique, qui s’exécute indépendamment du nombre de visiteurs. La constante DISABLE_WP_CRON se place dans wp-config.php, avant la ligne /* C'est tout, ne touchez pas à ce qui suit ! */ :

define( 'DISABLE_WP_CRON', true );
L'essentiel à retenir : WP-Cron ne se déclenche qu'à la visite d'une page ; DISABLE_WP_CRON coupe ce déclenchement implicite ; Un vrai cron système appelle wp-cron.php à intervalle fixe

Une fois cette constante activée, plus aucune vérification automatique n’a lieu au chargement des pages. Il devient nécessaire d’ajouter une entrée dans la table cron du serveur pour appeler régulièrement le script :

*/5 * * * * wget -q -O /dev/null https://exemple-association.fr/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Préférer WP-CLI à un appel HTTP direct

Un appel via wget ou curl fonctionne, mais reste dépendant de la configuration HTTP du site (redirections, pare-feu applicatif, authentification par mot de passe éventuelle sur l’environnement). Sur un serveur où WP-CLI est disponible, un appel direct en ligne de commande est plus fiable, car il court-circuite la couche HTTP :

*/5 * * * * cd /var/www/exemple-association.fr && wp cron event run --due-now --quiet

Cette approche présente un avantage supplémentaire : elle fonctionne même si le site est temporairement protégé par une authentification HTTP basique en environnement de recette, ce qui bloquerait un appel wget classique.

Vérifier que les tâches s’exécutent bien

Après la mise en place du vrai cron, la commande wp cron event list permet de vérifier que les tâches en attente diminuent au fil du temps plutôt que de s’accumuler :

  • wp cron event list pour lister les tâches programmées et leur prochaine exécution
  • wp cron test pour vérifier que le système de cron répond correctement
  • wp cron event run --due-now pour forcer l’exécution immédiate des tâches en retard

Un article qui se publie avec deux heures de retard n’est jamais un problème de rédaction : c’est presque toujours un problème de déclenchement. Vérifier DISABLE_WP_CRON et la présence d’un vrai cron système fait gagner un temps précieux avant de chercher plus loin.

Une fréquence adaptée, pas excessive

Un intervalle de cinq minutes convient à la grande majorité des sites, y compris ceux à trafic irrégulier. Descendre à une minute n’apporte généralement aucun bénéfice perceptible et multiplie inutilement les appels serveur. À l’inverse, un intervalle de quinze minutes ou plus peut retarder sensiblement la publication d’articles programmés à l’heure précise.

Pour aller plus loin

Ce dossier illustre une confusion fréquente chez les développeurs qui découvrent WordPress après avoir travaillé avec des systèmes de tâches planifiées classiques : WP-Cron n’est pas un démon qui tourne en arrière-plan, mais un mécanisme déclenché par le trafic, que DISABLE_WP_CRON associé à un vrai cron système permet de rendre parfaitement prévisible, y compris sur un site que personne ne visite la nuit.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Partager :

À propos de l'auteur

WordPress Développement

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi