Partir de deux sous-sites qui n’avancent pas de la même façon
Sur un réseau WordPress, les tâches automatiques du site principal se déroulent, mais un sous-site garde des événements en retard. Relevez une tâche attendue, son effet visible et l’heure prévue. Choisissez un sous-site qui fonctionne et un qui échoue. Vérifiez que la même fonction devrait être disponible sur chacun. Une extension peut être active pour un seul site, ou utiliser une file distincte de WP-Cron. Une tâche absente et une tâche en attente demandent des vérifications différentes.
WP-Cron conserve les événements dans le contexte du site. Un planificateur externe qui appelle seulement l’adresse du site principal ne constitue donc pas une preuve que les autres files sont traitées. L’objectif est de vérifier où le déclenchement arrive et quels événements progressent. Vous avez besoin d’un accès de lecture aux sites du réseau et au planificateur, ou de l’aide de la personne qui le gère. Pour vérifier une exécution, préparez une copie où les e-mails, paiements et appels externes sont isolés. Commencez par l’inventaire et les journaux. Ces lectures suffisent souvent à montrer qu’une cible manque.
Comparer le réseau et la configuration du planificateur
Relevez les sites actifs dans l’administration réseau ou dans l’outil de gestion déjà utilisé. Pour chacun, notez son identifiant, son adresse effective et le propriétaire de ses tâches. Identifiez les sites archivés ou sortis du périmètre. Un site peut avoir une adresse personnalisée qui diffère du sous-domaine ou du chemin attendu. Conservez cette adresse dans le relevé. Si l’installation héberge plusieurs réseaux, vérifiez aussi le réseau auquel appartient la cible. Une liste globale sans contexte peut inclure des sites qui ne devraient pas participer au même déclenchement.
Ouvrez ensuite la configuration du planificateur existant, par exemple l’interface de l’hébergeur ou le fichier maintenu par l’équipe système. Comparez les adresses ou les arguments de site avec l’inventaire. Relevez les heures, les commandes et le compte utilisé. Si la tâche planifiée produit un seul résultat global, cherchez une preuve pour chaque site dans ses journaux. Un code de fin général peut masquer une cible absente ou une erreur intermédiaire. Le résultat attendu est une liste qui relie chaque sous-site autorisé à un déclenchement observable.
Lire la liste des événements d’un sous-site ciblé
Si WP-CLI est déjà disponible, commencez par vérifier le chemin de l’installation et le site choisi. L’option url sélectionne le contexte du sous-site dans un réseau. L’exemple ci-dessous liste les événements sur une adresse fictive. Remplacez le chemin et l’adresse par ceux que vous avez vérifiés. Exécutez la même lecture pour le site témoin et pour celui qui présente le retard. Les colonnes proposées montrent le nom de l’événement, la prochaine exécution en temps universel et la récurrence.
Comparez la date de prochaine exécution au moment du relevé. Si elle est déjà passée, vérifiez si la même ligne reste présente à la prochaine observation. Si le hook manque, vérifiez l’activation du composant et ses conditions de planification sur ce sous-site. Si l’heure avance mais que l’effet attendu n’apparaît pas, cherchez le résultat du traitement dans le journal métier. Pour des hooks répétés, comparez les arguments dans un espace privé. Une même étiquette peut désigner des opérations différentes. Le listing est une lecture de planification. Il ne démontre pas que le travail associé a abouti.
wp --path=/chemin/verifie/wordpress --url=https://sous-site.exemple.test/ cron event list --fields=hook,next_run_gmt,recurrenceVérifier quel mécanisme lance les événements
Déterminez si le réseau repose sur le déclenchement habituel lors de visites ou sur un planificateur externe. L’option DISABLE_WP_CRON est souvent utilisée lorsqu’un déclenchement externe prend le relais. Lisez sa valeur dans la configuration maintenue. Si l’appel extérieur ne couvre que l’accueil du réseau, d’autres sous-sites peuvent attendre indéfiniment. Si le déclenchement lié aux visites reste actif, comparez la fréquentation et la manière dont le site répond aux visites. Un sous-site peu visité peut présenter un rythme différent.
Sur une configuration externe, vérifiez l’heure système, l’utilisateur du processus et le résultat pour chaque adresse. Pour un appel HTTP, suivez la destination jusqu’au document réellement atteint. Une redirection, une authentification intermédiaire ou une erreur de certificat peut empêcher l’appel d’arriver au site voulu. Pour un appel WP-CLI, vérifiez le binaire, le dossier et l’argument url. Ces deux méthodes ont des accès différents. Retenez celle que l’équipe peut observer et maintenir dans l’environnement concerné. Gardez une trace de l’ancien mécanisme avant d’en changer la fréquence ou le périmètre.
Traiter une file absente avant de changer la cadence
Si le hook attendu n’existe pas sur un sous-site, ouvrez le composant qui le crée. Vérifiez si sa fonction s’applique à ce sous-site et si la configuration nécessaire est présente. Un composant activé pour tout le réseau peut encore conditionner certains travaux à un réglage local. Comparez les versions et les options entre le site témoin et celui qui échoue. Recherchez aussi si le composant utilise une file distincte. Les actions planifiées d’une extension peuvent être visibles dans son propre écran et ne correspondent pas toutes à un événement WP-Cron individuel.
Sur la copie, suivez la procédure du fournisseur pour déclencher la création de l’événement lorsqu’elle existe. Relisez ensuite la file dans le contexte du sous-site. Une ligne future avec la récurrence voulue confirme que le composant a créé sa tâche. Vérifiez aussi que les autres sites n’ont pas reçu une occurrence supplémentaire. Si le hook apparaît mais reste en retard, revenez au planificateur. Si l’événement disparaît après exécution sans être renouvelé, vérifiez qu’il était censé être récurrent et que la fonction reste chargée.
Éprouver un déclenchement sur une seule cible de test
Préparez un sous-site de test avec les mêmes paramètres utiles et une tâche attendue dont vous pouvez vérifier l’effet. Examinez tous les événements arrivés à échéance avant d’utiliser une exécution groupée. Un appel qui exécute les tâches dues peut lancer plusieurs travaux sur ce site. Si l’un d’eux a des effets non isolés, préparez un autre environnement ou un scénario de test plus restreint. Préservez l’état initial de la copie afin de pouvoir reproduire l’essai.
Lorsque les événements dus du sous-site sont contrôlés, la commande ci-dessous exécute ceux qui sont arrivés à échéance dans le contexte ciblé. Adaptez le chemin et l’adresse. Relevez la sortie et relisez la file après l’exécution. Vérifiez l’effet métier prévu, par exemple la mise à jour d’un brouillon de test ou une trace interne. Si une tâche est reportée ou échoue, conservez son message. Une exécution manuelle réussie confirme le fonctionnement de cette cible. Elle ne suffit pas encore à vérifier que le planificateur l’appelle au bon moment.
wp --path=/chemin/verifie/wordpress --url=https://sous-site.exemple.test/ cron event run --due-nowAjouter seulement les sous-sites autorisés
Si la comparaison montre qu’une cible manque, ajoutez son adresse à la configuration du planificateur maintenue par l’équipe. Utilisez le même binaire et le même compte que la cible déjà validée, sauf si l’infrastructure impose un autre accès. Pour une petite liste stable, une entrée explicite par sous-site permet de connaître son périmètre. Pour un réseau qui change souvent, faites produire une liste de cibles approuvées à partir de l’inventaire et des exclusions de l’équipe. Gardez les adresses exactes qui seront utilisées.
Évitez de déclencher toutes les files à partir d’une liste brute. Un site de test, archivé ou séparé peut apparaître dans l’inventaire sans appartenir au plan de travail. Une commande sur tout le réseau dépend également des capacités de la version WP-CLI installée. Les commandes ciblées permettent de vérifier le résultat de chaque site. Définissez comment le journal affiche les heures, les cibles et les erreurs, sans recopier de données privées. Si un sous-site échoue, les autres résultats doivent rester identifiables. Testez un seul ajout avant d’étendre le réglage à d’autres sites.
Prévoir la fréquence et les exécutions qui se chevauchent
Relevez la durée habituelle de l’exécution sur la copie et les besoins de la tâche. Une fréquence trop élevée par rapport au temps de traitement peut démarrer un passage alors qu’un autre est encore actif. Le mécanisme de protection dépend du trajet et du planificateur. Faites vérifier comment l’équipe évite deux passages concurrents sur une même cible. Une file qui ne progresse pas malgré de nombreux appels mérite une lecture de l’erreur et des effets déjà produits.
Si plusieurs sites traitent beaucoup de travail, choisissez des horaires qui répartissent la charge lorsque le planificateur le permet. Conservez la fréquence nécessaire aux tâches sensibles. Pour une tâche de nettoyage qui peut attendre, une cadence différente peut être acceptable. Documentez les décisions par type de travail. Si le site reçoit une demande d’exécution pendant une maintenance, vérifiez comment cette demande est reportée ou journalisée. Le but est un déclenchement observé et suffisamment régulier pour la fonction prévue. Un pic d’activité après reprise peut demander de traiter d’abord la file en retard dans l’environnement contrôlé.
Vérifier l’effet d’une demande HTTP prévue par l’hébergeur
Lorsque l’hébergeur prévoit un appel HTTP de wp-cron.php, relevez l’adresse propre au sous-site et confirmez qu’elle atteint l’installation attendue. Faites vérifier la destination après redirection, le résultat du trajet et l’heure du passage. Une réponse 200 peut seulement signifier que le point d’entrée a répondu. Comparez ensuite la liste des événements et l’effet métier. Si un domaine personnalisé vient de changer, vérifiez que le planificateur utilise encore l’adresse officielle et que l’origine reçoit cette demande.
Si le trajet est bloqué par une protection, demandez au responsable de préparer une voie autorisée pour ce déclenchement ou d’utiliser la méthode locale prévue par l’hébergeur. Gardez les règles qui protègent les autres chemins. Si le trajet atteint un autre site, corrigez l’adresse avant d’augmenter la cadence. Sur la copie, vérifiez que la file du site témoin avance et que celle d’un site hors périmètre conserve son fonctionnement attendu. Consignez le mode de déclenchement retenu avec l’identité du propriétaire et les traces utilisées pour le vérifier.
Préparer le retour du planificateur
Avant d’ajouter une cible ou de modifier une fréquence, conservez la configuration précédente et le relevé des événements. Pour annuler, retirez la seule cible ou restaurez sa fréquence et le trajet précédent. Vérifiez ensuite la prochaine exécution attendue. Si vous avez changé le mécanisme lié aux visites, rétablissez la valeur prévue et l’ancienne tâche externe de manière cohérente. Deux mécanismes actifs peuvent produire des passages supplémentaires. Un arrêt simultané peut au contraire laisser toutes les files en attente.
Une tâche déjà exécutée peut avoir envoyé une notification ou mis à jour un dossier. Le retour du planificateur ne défait pas cet effet. Vérifiez son état auprès du système destinataire avant de relancer. Si une reprise est nécessaire, choisissez le mécanisme de rattrapage documenté pour cette tâche et conservez le résultat. Sur une copie, rétablissez le point de départ lorsque vous devez répéter l’expérience complète. Sur le site actif, préservez les opérations indépendantes qui ont eu lieu depuis le changement. Le retour du déclenchement et celui des données demandent des décisions distinctes.
Valider la couverture après deux passages
Relevez une cible qui fonctionnait déjà et la cible ajoutée. Pour chacune, gardez une tâche attendue et le moyen de vérifier son effet. Faites la première lecture avant l’heure du planificateur et la suivante après son passage. Si la file se renouvelle, confirmez aussi le prochain horaire. Un passage manuel peut avoir consommé l’événement de test. Utilisez un événement attendu lors du passage normal pour la validation finale.
- Confirmez le réseau et les adresses des sous-sites couverts.
- Vérifiez la file de la cible avec l’adresse et le chemin de l’installation.
- Lisez le journal du planificateur et comparez son heure au changement de la file.
- Vérifiez l’effet de la tâche dans le système prévu.
- Refaites le relevé au passage suivant et contrôlez le site déjà couvert.
- Conservez la liste des cibles, les exclusions et la configuration de retour. Notez séparément les tâches qui ont leur propre mécanisme ou dont le traitement reste à diagnostiquer.
Entretenir la liste quand le réseau change
Ajoutez au dossier d’exploitation le nom du planificateur, sa configuration, le compte qui l’exécute et les personnes qui peuvent modifier les cibles. Pour chaque sous-site, indiquez son adresse actuelle, son rôle et la preuve attendue de progression. Lors de l’ajout ou de l’archivage d’un site, vérifiez si cette liste doit changer. Un changement de domaine ou de chemin peut aussi laisser une cible devenue inutilisable. Gardez un exemple de contrôle sur un site peu visité afin de détecter un déclenchement qui dépend encore du trafic.
WP-CLI est une option lorsque le terminal et l’outil sont déjà disponibles. Un planificateur HTTP géré par l’hébergeur peut convenir lorsque l’équipe en maîtrise la destination et les traces. Pour chaque méthode, vérifiez la version et les options réellement installées. Le choix de la méthode peut varier selon les accès. La couverture du réseau se démontre avec une cible et un résultat par site autorisé. Conservez ces preuves après une mise à jour ou une migration pour reprendre rapidement le diagnostic.
