Le cron WordPress intervient dans des opérations qui doivent se produire plus tard : publication programmée, vérification de mises à jour ou traitements ajoutés par des extensions. Une date enregistrée ne prouve pourtant ni le déclenchement ni la réussite de l’opération. Avant de modifier un réglage, identifiez la tâche attendue et le résultat qui manque.
Programmé ne signifie pas terminé
- 01Prévoir
Une opération et une échéance sont enregistrées.
- 02Déclencher
WordPress reçoit l’occasion de lancer les tâches dues.
- 03Exécuter
Le composant concerné effectue son traitement.
- 04Vérifier
Le résultat attendu est réellement disponible.
WP-Cron : à quoi servent les tâches planifiées WordPress ?
- Publier au moment prévu un article programmé.
- Déclencher des vérifications périodiques, notamment pour les mises à jour.
- Exécuter certains traitements d’extensions, selon leur fonctionnement et leur configuration.
WP-Cron est le mécanisme de planification intégré au logiciel. Ce cron WordPress traite une liste d’événements arrivés à échéance. Un événement associe notamment un identifiant technique, appelé hook, une prochaine exécution et, s’il est récurrent, un intervalle.
Toutes les sauvegardes et tous les envois ne dépendent pas forcément du cron WordPress. Un service distant ou l’hébergeur peut utiliser son propre système. Commencez par la documentation de l’outil qui réalise l’opération ; la présence d’une extension ne décrit pas toute la chaîne.
Repérer le responsable de chaque automatisation
Notez l’opération attendue, le logiciel qui l’effectue, la fréquence choisie et l’endroit où consulter son résultat. Pour une sauvegarde, le guide pour sauvegarder et restaurer WordPress détaille les copies à préparer et leur vérification ; nous examinons ici leur déclenchement éventuel.
Comment se déclenche le cron WordPress ?
Par défaut, WordPress vérifie les événements échus lors du chargement des pages. WP-Cron ne tourne donc pas en permanence comme un planificateur système. La documentation officielle de WP-Cron explique pourquoi une échéance peut être dépassée avant qu’une occasion de traitement se présente.
Exemple pédagogique · site sans autre déclencheur
Aucun chargement de page ne déclenche encore le traitement.
WordPress peut lancer la vérification des événements échus.
Le traitement peut réussir ou rencontrer une erreur distincte.
Sur un site peu visité, le déclenchement habituel peut être insuffisant pour une opération sensible à l’heure. Mais un retard du cron WordPress ne démontre pas, à lui seul, un manque de trafic : une restriction d’accès, une erreur ou une configuration différente peut aussi intervenir.
Une file applicative comme Action Scheduler constitue encore un autre niveau de traitement. Ne confondez pas sa liste d’actions avec les événements WP-Cron : vérifiez le mécanisme réellement employé avant d’appliquer une correction.
Comment distinguer un retard d’un échec ?
Comparez l’heure prévue, les traces d’exécution et le résultat obtenu. Un événement en retard et un événement lancé mais interrompu ne se corrigent pas forcément au même endroit. Conservez aussi le fuseau horaire affiché pour comparer des heures comparables.
| Observation | Ce qu’elle permet de dire | Contrôle suivant |
|---|---|---|
| L’échéance est dépassée | L’événement semble en attente dans la liste consultée. | Vérifier le déclencheur et les messages disponibles. |
| Un lancement apparaît, puis une erreur | Un traitement a commencé sans aboutir normalement. | Lire la trace et identifier le composant concerné. |
| L’événement n’est pas trouvé | La liste examinée ne montre pas cette programmation. | Confirmer l’outil, son activation et son propre planificateur. |
| Le résultat est disponible | L’opération observée a produit l’élément attendu. | Contrôler aussi la prochaine occurrence si elle est récurrente. |
Le cron WordPress n’est pas la cause automatique de tout mail manquant ou fichier absent. Une opération peut échouer après son démarrage : stockage indisponible, erreur applicative ou livraison du message. Évitez de relancer plusieurs fois un envoi ou une opération commerciale sans comprendre ce qui a déjà été exécuté.
Comment consulter les événements sans les modifier ?
Pour examiner le cron WordPress, utilisez d’abord les informations déjà disponibles dans l’administration et chez l’hébergeur. Si un outil de lecture est nécessaire, WP Crontrol permet de consulter les événements, leurs arguments, leur récurrence et leur prochaine exécution. Son installation reste une modification à préparer.
Une lecture dans l’ordre
- Ouvrez la liste des événements. La documentation actuelle indique Cron → Cron Events ; Outils → Événements Cron reste aussi accessible selon la version.
- Repérez le hook et le composant. Un nom technique seul ne justifie pas une suppression.
- Relevez la prochaine exécution et la récurrence. Notez les avertissements éventuels et l’heure du contrôle.
- Consultez les journaux disponibles. Une liste d’échéances ne constitue pas automatiquement un historique des exécutions passées.
La présentation et les fonctions de journalisation peuvent évoluer. Vérifiez celles de la version installée avant de conclure qu’une trace existe ou manque. Pour un accès de diagnostic temporaire, choisissez un compte autorisé et ne partagez pas un export contenant des données privées.
Lire n’est pas relancer. Les commandes « exécuter », « supprimer » ou « suspendre » modifient le fonctionnement. Ne les utilisez pas en lot pour nettoyer une liste : certains événements du cron WordPress sont nécessaires aux composants encore actifs.
Que vérifier si les tâches planifiées ne partent plus ?
- Le périmètre : un événement précis ou plusieurs opérations touchées.
- Le déclencheur : fonctionnement habituel ou relais déjà configuré.
- Les traces : erreurs, restrictions et changements récents.
Procédez par hypothèses vérifiables. La documentation des événements en retard de WP Crontrol recense plusieurs causes possibles. Elle ne permet pas de choisir la bonne sans examiner votre installation.
Le site peut-il lancer son traitement ?
Une protection de préproduction, un pare-feu ou un problème de requête interne peut gêner le déclenchement. Consultez les messages et les journaux avant de modifier une protection. Un site accessible dans votre navigateur ne prouve pas que son appel interne fonctionne.
Un composant interrompt-il l’exécution ?
Rapprochez l’heure du problème des erreurs PHP et des modifications récentes. Si une extension est suspectée, préparez un test isolé sur une copie adaptée ; ne désactivez pas tous les outils du site public. Le guide de création d’un site de test WordPress explique comment séparer ces essais de l’activité réelle.
Vérifiez enfin si le cron WordPress a volontairement été confié à un autre déclencheur. Un relais supprimé ou arrêté peut laisser des événements enregistrés sans exécution. Notez les constats avant de toucher à la configuration : le réglage actuel peut répondre à une contrainte de l’hébergement.
Quand prévoir une tâche cron sur le serveur ?
Un déclencheur indépendant des visites peut être pertinent quand les horaires comptent ou que le fonctionnement habituel ne convient pas. Ce choix dépend de l’hébergement, de la fréquence nécessaire et des outils déjà en place. Il ne constitue pas une correction universelle du cron WordPress.
Préparer le relais avant de retirer l’ancien déclenchement
- 1Identifier
L’installation, la fréquence et le mécanisme existant.
- 2Configurer
Le relais compatible avec l’hébergement.
- 3Tester
Son appel et le résultat d’une opération appropriée.
- 4Basculer
Puis vérifier de nouveau et conserver le retour arrière.
La procédure officielle de raccordement au planificateur système distingue la tâche externe et le réglage DISABLE_WP_CRON. Passer ce réglage à true empêche le déclenchement habituel au chargement des pages ; cela ne crée pas un relais à votre place.
Ne désactivez pas le déclenchement sans relais opérationnel. Faites confirmer le chemin, la version PHP ou l’URL appelée, l’intervalle et les conditions d’accès propres à l’hébergement. Conservez une copie récupérable de la configuration modifiée.
Pour le cron WordPress, l’intervalle doit correspondre aux besoins réellement identifiés. Une fréquence choisie au hasard, ou plusieurs déclencheurs ajoutés pour compenser un défaut mal compris, ne démontre pas une amélioration. Les réglages d’un autre hébergeur ne sont pas une preuve de compatibilité avec le vôtre.
Comment vérifier que l’automatisation a vraiment abouti ?
Terminez le contrôle du cron WordPress par le résultat métier. Un message « lancé » est une étape intermédiaire ; l’absence d’alerte n’est pas une confirmation de réussite. Choisissez un événement de test sans envoi ou transaction involontaire lorsque c’est possible.
Exemple pédagogique · sauvegarde programmée
Composants inclus, emplacement et échéance identifiés.
Lancement et éventuelles erreurs du logiciel examinés.
Présence, contenu et méthode de restauration contrôlés.
Documentez l’opération, l’heure, le résultat et les réserves. Observez ensuite une occurrence normale : une exécution manuelle réussie ne démontre pas que la programmation suivante fonctionnera. Pour les mises à jour, conservez les contrôles après mise à jour WordPress ; le déclencheur ne remplace pas la recette du site.
Une vérification reproductible
- Avant : échéance, tâche et résultat attendu.
- Après : résultat observé, heure et éventuelle erreur.
- Dans la durée : prochaine occurrence et personne qui traite une alerte.
La surveillance du cron WordPress complète celle de la disponibilité. Le guide du monitoring de site web concerne les alertes et contrôles de disponibilité ; une page d’accueil en ligne ne prouve pas que les traitements programmés fonctionnent.
Questions fréquentes sur le cron WordPress
WP Crontrol répare-t-il automatiquement les tâches ?
Non. Il aide à consulter et gérer les événements, mais ne remplace pas le diagnostic du déclencheur ou du composant. Sa documentation précise qu’il ne modifie pas le mécanisme d’exécution du cœur WordPress.
Peut-on supprimer un événement dont le nom est inconnu ?
Identifiez d’abord son propriétaire et son rôle. L’absence de nom compréhensible ne signifie pas qu’il est inutile. Une suppression peut interrompre une fonction ; un composant peut aussi recréer son événement.
Faut-il une tâche serveur toutes les cinq minutes ?
Ce n’est pas une règle universelle. L’intervalle dépend du délai acceptable, des opérations, des ressources et des possibilités de l’hébergement. Faites valider le réglage adapté et le suivi de son exécution.
Un événement en retard signifie-t-il que le site est piraté ?
Non. Le retard seul ne permet pas ce diagnostic. Recherchez des éléments concordants : erreurs, configuration, accès et changements récents. Traitez un indice de compromission séparément plutôt que de l’attribuer automatiquement au planificateur.
Quel suivi prévoir pour vos tâches programmées ?
Pour chaque tâche cron WordPress importante, faites préciser le résultat à contrôler, la personne qui reçoit les alertes et la vérification attendue après intervention. Une fonction « activée » et un suivi réellement organisé sont deux choses différentes. Mon accompagnement en maintenance WordPress permet de définir le suivi adapté à votre site et aux outils utilisés.
Pour fiabiliser le cron WordPress, gardez une démarche simple : identifier l’opération, vérifier son déclenchement, constater le résultat et suivre la prochaine occurrence.
