Définir l’ancien traitement à arrêter
Après une migration, un planificateur d’hébergement peut encore appeler le WordPress précédent. Une commande PHP peut viser un ancien dossier, tandis qu’une commande HTTP qui utilise le domaine public peut désormais atteindre le nouveau site. Dans ce second cas, l’ancien hébergement peut déclencher les tâches du site actuel. Avant de retirer une ligne, identifiez la cible réelle, le propriétaire du traitement et l’endroit où le déclenchement doit être conservé.
Relevez le symptôme qui motive l’intervention. Il peut s’agir d’un journal d’accès sur l’ancien serveur, d’un envoi répété ou d’une tâche facturée qui ne devrait plus exister. Une heure de journal répétée selon un intervalle est un indice. Rapprochez-la de la configuration du planificateur et du fuseau qu’il utilise. Un processus lancé manuellement peut aussi produire une entrée semblable. Conservez les observations avant toute modification.
Le retrait porte ici sur le lanceur système ou l’appel externe. Les événements stockés dans WordPress et les tâches applicatives restent à traiter séparément si leur suppression est prévue. Une opération de migration peut exiger que ces événements restent présents sur le nouveau site, avec un seul mécanisme chargé de les déclencher.
Lire la commande et la fréquence dans cPanel
Ouvrez Avancé, Cron Jobs, puis la liste des tâches existantes. Relevez la commande entière, l’intervalle et les réglages de notification. Si le fournisseur utilise une autre interface, demandez les mêmes informations pour le compte d’hébergement concerné. Copiez ces éléments uniquement dans le dossier privé de maintenance. Une URL de déclenchement ou une commande peut contenir un secret, un identifiant ou un chemin interne. Le support peut recevoir une version expurgée.
Distinguez une commande qui exécute directement un fichier PHP d’une commande qui appelle une URL. Relevez le binaire, le chemin de script, les options, le répertoire de travail éventuel et les redirections de sortie. Un script intermédiaire peut choisir lui-même le site ou lancer plusieurs traitements. Ouvrez sa copie autorisée pour déterminer cette logique sans l’exécuter. Si une commande est trop complexe ou si sa provenance reste inconnue, faites intervenir son propriétaire.
Un réglage de courriel vide ou une sortie redirigée vers un puits peut supprimer les notifications sans arrêter la tâche. La fin des courriels n’atteste donc pas la fin du déclenchement. Le relevé doit conserver la commande et les horaires, pas seulement l’adresse qui recevait ses messages.
Confirmer la cible d’un appel HTTP
Pour une commande qui contacte le domaine public, demandez où ce nom se résout depuis l’ancien hébergement et s’il suit les redirections. Le DNS du serveur peut différer de celui de votre poste. Un fichier local de résolution ou une configuration du client peut également imposer une adresse. Évitez d’exécuter la commande complète pour découvrir sa destination si elle déclenche des écritures, des messages ou une tâche métier.
Rapprochez le nom, les options du client et les journaux d’accès existants. Si vous voyez un appel régulier à wp-cron.php sur le nouveau serveur, recherchez si son origine correspond à l’ancien planificateur. Une adresse partagée peut exiger une confirmation du fournisseur. Si le nom redirige, déterminez la destination sans appeler l’action sensible, avec les outils de lecture et les traces déjà disponibles.
Le propriétaire doit confirmer si ce lanceur constitue encore le mécanisme officiel de la production. Il peut avoir été conservé temporairement pendant la migration pour maintenir la régularité des tâches. Le retirer avant la mise en place de son remplaçant peut laisser le site public sans déclenchement attendu. Notez l’état du mécanisme de relève et la preuve de son fonctionnement avant de supprimer l’ancienne ligne.
Confirmer la cible d’un lancement PHP ou WP-CLI
Pour une commande locale, identifiez le chemin résolu du script et la racine WordPress qu’il charge. Un lien symbolique vers le dossier courant peut pointer vers un autre paquet que celui suggéré par son nom. Un script maison peut inclure wp-load.php depuis un emplacement calculé. Demandez la référence de déploiement et la base attendue pour confirmer la cible avec une source indépendante. Le nom d’un dossier appelé ancien ne prouve pas qu’il est hors service.
Vérifiez le compte système et le PHP utilisés par le planificateur. Ils peuvent différer du contexte de votre session SSH. Une commande qui fonctionne dans un terminal interactif peut recevoir d’autres variables ou permissions dans cron. Relevez la configuration et les journaux d’exécution déjà présents avant de proposer une correction. Les accès de lecture suffisent souvent à identifier la cible sans lancer le traitement.
Si l’ancien dossier continue d’utiliser la base courante, bloquez toute conclusion selon laquelle le traitement est sans effet sur la production. Faites confirmer ce partage au responsable. La décision peut porter d’abord sur la séparation des accès ou sur la reprise du traitement par le bon service, avec un plan d’arrêt de l’ancien lanceur.
Observer les événements de la cible autorisée
Lorsque la racine et le code chargé ont été reconnus comme autorisés, WP-CLI peut relever les événements planifiés du site. L’exemple ci-dessous liste leurs noms et leurs prochaines dates relatives. Il ne demande pas l’exécution des événements. Remplacez le chemin par celui de la cible confirmée et gardez l’inventaire dans l’espace privé. L’initialisation de WordPress charge son code, ce qui justifie une voie statique si l’ancienne copie est suspecte ou ne doit plus démarrer.
Comparez la liste aux fonctions métier connues. Des événements de publication, d’envoi ou d’entretien peuvent rester nécessaires sur le nouveau site. Leur présence dans l’ancienne base indique un potentiel de travail, sans prouver qu’un lanceur les traite encore. Rapprochez l’inventaire du journal existant et de l’état du planificateur. Évitez de lancer tous les événements échus pour tester l’hypothèse.
Sur le site actuel, confirmez quel mécanisme est censé déclencher WP-Cron et si DISABLE_WP_CRON a été défini dans sa configuration. Cette constante empêche le déclenchement habituel lié aux visites, mais n’est pas une preuve que les appels externes ou les tâches système ont disparu. Vérifiez la configuration du lanceur séparément.
wp --path=/chemin/vers/wordpress cron event list --fields=hook,next_run_relative,recurrencePréparer l’arrêt avec l’état des traitements en cours
Conservez la commande et l’horaire exacts dans le dossier privé, avec leur propriétaire. Demandez au fournisseur si l’interface propose une suspension documentée ou seulement une suppression. Préparez le moyen de remettre la ligne si une dépendance légitime a été oubliée. La copie de configuration doit préserver les arguments et le contexte, tout en gardant les secrets dans le coffre. Une capture d’écran publique ne convient pas à cette sauvegarde.
Vérifiez si un traitement lancé par cette ligne est encore actif. La suppression du prochain déclenchement ne termine pas nécessairement un processus déjà démarré. Si un traitement est en cours, relevez sa référence et demandez à son propriétaire le point d’arrêt sûr ou la confirmation de sa fin. Évitez d’interrompre au hasard un processus qui peut écrire des données, transmettre un lot ou détenir un verrou.
Confirmez également la reprise sur le bon service. Si l’ancien lanceur réalisait un travail nécessaire, le remplaçant doit avoir produit la preuve attendue avant l’arrêt définitif. Pour un traitement d’écriture, identifiez le dernier lot réussi et la manière d’éviter une reprise en double. Inscrivez les conditions qui déclencheraient un retour.
Retirer le seul déclenchement devenu inutile
Dans l’interface d’hébergement, sélectionnez l’entrée attribuée et appliquez l’action de suspension ou de suppression prévue. cPanel documente une action Delete sur la ligne concernée, suivie de sa confirmation. Vérifiez la commande affichée avant validation, surtout si plusieurs lignes utilisent le même domaine avec des arguments différents. Une entrée peut appeler une sauvegarde, une autre le moteur WordPress. Le retrait doit rester lié à l’usage validé.
Si le planificateur est produit par un dépôt ou une configuration serveur, faites corriger cette source. Une suppression locale peut être rétablie au prochain déploiement. Demandez l’identifiant de la version de configuration publiée et vérifiez la liste obtenue. Dans un parc de serveurs, chaque instance peut posséder sa propre ligne. Le contrôle doit couvrir les emplacements qui peuvent déclencher le traitement, selon l’inventaire.
Laissez les événements WordPress utiles en place sur le site de destination. La suppression d’un lanceur n’implique pas l’effacement de la file applicative. Si une ancienne copie doit être retirée entièrement, préparez cette opération séparée après avoir vérifié ses données, accès et usages résiduels.
Dans cPanel, la table Current Cron Jobs permet d’identifier la ligne à retirer. Le parcours documenté utilise Delete sur cette ligne, puis une seconde confirmation Delete. Conservez les cinq champs de planification et la commande entière avant confirmation. Pour une restauration autorisée, Add New Cron Job permet de remettre ces valeurs exactes ; les presets Common Settings ne remplacent pas la fréquence sauvegardée. Comparez le fuseau du planificateur et celui des journaux avant de choisir la prochaine fenêtre d’observation.
Vérifier l’absence de nouveau départ au bon moment
Attendez une échéance où la ligne aurait dû se déclencher, puis consultez la liste du planificateur et les journaux prévus. Relevez l’heure de la vérification, le fuseau et la période couverte. Un intervalle de cinq minutes peut se contrôler rapidement, tandis qu’une tâche mensuelle demande une autre preuve. Le fournisseur peut confirmer que la ligne n’existe plus dans la source publiée. Distinguez cette confirmation de configuration d’une observation sur toute une période d’exécution.
Vérifiez aussi la fin des processus déjà lancés lorsque leur arrêt faisait partie du plan. L’absence d’un nouveau départ ne prouve pas que le dernier traitement a terminé. Demandez une référence de fin ou un état métier confirmé par son propriétaire. Si un ancien appel HTTP continue, recherchez un autre planificateur ou un service externe qui utilise la même URL avant de modifier le WordPress de destination.
Sur le site actuel, observez le prochain travail attendu. Par exemple, vérifiez un événement de démonstration ou un journal d’entretien prévu qui n’entraîne pas d’action externe non autorisée. La preuve doit confirmer que le mécanisme nécessaire reste opérationnel après le retrait de l’ancien lanceur.
Traiter les doublons découverts pendant l’observation
Une migration peut laisser deux mécanismes légitimes apparents, comme un planificateur cPanel et un service de surveillance externe. Comparez leurs horaires, leurs destinations et leurs propriétaires. Identifiez lequel doit rester maître du déclenchement. La présence de plusieurs appels à wp-cron.php ne signifie pas nécessairement que chaque événement est exécuté deux fois, car WordPress possède ses propres mécanismes de coordination. Toutefois, les scripts maison ou tâches métier peuvent avoir d’autres règles.
Si vous observez une répétition métier, relevez les identifiants de lots et le résultat réellement produit. Une double notification, une double écriture ou une hausse du nombre de requêtes demandent des contrôles différents. Évitez de rejouer les traitements avant d’avoir rapproché l’état courant. Le retrait du lanceur corrige les départs futurs, mais ne répare pas automatiquement les données déjà modifiées.
Pour une ligne qui revient après suppression, vérifiez la gestion de configuration et le compte propriétaire. Un service d’hébergement peut recréer une tâche nécessaire à son offre. Faites confirmer son rôle et demander la correction au niveau responsable, avec une trace qui précise le site et la destination attendus.
Revenir en arrière sans relancer un lot inconnu
Si un service utile s’arrête après le retrait, identifiez d’abord la tâche et son dernier résultat confirmé. Rétablissez la ligne précédente seulement si le plan de retour l’autorise et si sa cible reste correcte. Une commande HTTP peut viser une autre destination depuis le changement DNS. Une restauration aveugle de l’ancienne ligne peut donc déclencher le traitement sur le mauvais WordPress. Relisez le contexte et les arguments avant de l’activer.
Pour une tâche suspendue qui accumule des éléments, demandez au propriétaire comment reprendre la file. Une remise du calendrier peut faire traiter rapidement un retard important. Vérifiez les limites de débit et les effets sur les services externes selon le mécanisme utilisé. Ne combinez pas ce retour avec une exécution manuelle du même lot sans coordination.
Si le problème vient d’un autre changement, comme une nouvelle version PHP ou une variable manquante, faites traiter cette cause. La réactivation du lanceur historique ne prouve pas qu’il constitue la bonne architecture durable. Après retour, confirmez le résultat métier et inscrivez la prochaine décision pour qu’un mécanisme temporaire ne devienne pas permanent sans propriétaire.
Documenter la fin de service de l’ancien lanceur
La remise finale doit contenir le compte d’hébergement, la commande expurgée, sa référence privée complète, la cible confirmée et le mécanisme qui prend la relève. Ajoutez l’heure du retrait, l’état du dernier traitement et la période observée sans nouveau départ. Si vous n’avez pas pu examiner un processus ou une tâche rare, attribuez cette vérification à son responsable. Le prochain mainteneur doit pouvoir comprendre quelle partie a été arrêtée et quelle fonction reste attendue sur le site actuel.
Les interfaces de tâches et le shell dépendent de l’offre d’hébergement. Les commandes d’inventaire WordPress utilisent WP-CLI lorsqu’il est disponible. La méthode ne nécessite pas d’extension supplémentaire ni d’achat lorsque ces accès sont déjà fournis. Si le fournisseur gère les tâches, demandez le périmètre de son intervention et la preuve de configuration qu’il peut remettre.
Ajoutez enfin le contrôle des lanceurs à la réception d’une migration. Un relevé du planificateur d’origine et de celui de destination, associé aux files applicatives, permet de décider plus tôt quel serveur doit encore exécuter du travail.
L’Atelier WordPress.
