WP-Cron : une tâche ne se reprogramme plus, erreur invalid_schedule

Lire l’erreur au bon niveau

Dans le journal PHP, WordPress écrit Cron reschedule event error, suivi d’un nom de tâche, du code invalid_schedule et du message Event schedule does not exist. Un fil du forum décrit ce signal pour wsal_generate_reports_cron, avec la récurrence tenminutes et un intervalle enregistré de 600 secondes. Ce signal appelle une vérification précise : WordPress peut atteindre une tâche arrivée à échéance et échouer au moment d’inscrire sa prochaine exécution. L’heure du journal ne dit pas si le traitement métier de cette occurrence a réussi, et le fil ne permet pas de généraliser sa cause à toutes les versions d’une extension.

Séparez trois éléments. Le hook désigne l’action à appeler, par exemple pour générer un rapport. La clé de récurrence nomme le rythme, par exemple tenminutes. L’intervalle est une durée en secondes. La file peut encore contenir le nom et l’intervalle d’un ancien événement, alors que le code qui enregistre la récurrence n’est plus chargé. Le cœur peut relire l’intervalle stocké pendant la tentative de replanification ; la fonction qui inscrit l’échéance doit tout de même reconnaître la clé. Voir interval: 600 dans le journal ne démontre donc pas que la récurrence est disponible.

Ne traitez pas toutes les erreurs de planification de la même façon. could_not_set appelle un examen de l’écriture de la file. Un échec d’appel interne concerne le déclenchement. Ici, le message indique que la replanification de cette tâche a été tentée. Si des tâches différentes ne démarrent jamais et qu’il n’y a pas cette trace, utilisez le diagnostic général de WP-Cron. Si une seule tâche échoue avec invalid_schedule alors que les autres continuent, partez de la clé et de son propriétaire.

1. Relevez le hook, la clé de récurrence, la date du journal avec son fuseau et, si elle est connue, la date du dernier résultat métier. Ne copiez pas les arguments d’un événement dans un canal partagé.
2. Cherchez la même erreur autour de deux échéances. Une trace isolée au moment d’une mise à jour peut ne plus se reproduire ; une prochaine échéance vérifiée donne une meilleure indication.
3. Choisissez un témoin indépendant, par exemple une tâche de recette qui produit une trace sans envoyer d’e-mail. Elle permettra de vérifier que le lanceur fonctionne pendant que vous corrigez la récurrence ciblée.

Vérifier le propriétaire avec le tableau de bord et les journaux

Cette voie convient si vous gérez WordPress et pouvez lire le journal de l’hébergement, sans ouvrir de terminal. Dans le tableau de bord, ouvrez Extensions > Extensions installées. Relevez la version et l’état de l’extension qui porte la fonction mentionnée par le journal. Vérifiez également si l’extension est gérée au niveau du réseau. Le nom d’un hook est un indice ; confirmez son propriétaire dans la documentation de l’éditeur ou auprès de la personne qui maintient le code, surtout si une extension maison utilise un nom générique. Il n’est pas nécessaire de désactiver des extensions au hasard pour établir ce lien.

Sur une copie isolée, utilisez l’écran de l’extension qui configure la fonction liée à cette tâche. Relevez l’ancien rythme et le résultat qu’elle doit produire. Pour un générateur de rapports, remplacez si possible le destinataire par une boîte de test et empêchez les sorties externes de la copie. Si l’éditeur documente une correction applicable à votre version, installez-la dans la copie. Si l’éditeur indique que l’enregistrement de la périodicité recrée l’événement, utilisez ce bouton une fois. Certains écrans enregistrent une préférence sans recréer un événement : n’interprétez pas le message de succès du formulaire comme un test de la file.

Si vous n’avez ni accès au journal ni moyen de vérifier un résultat, transmettez le nom de la tâche, la version de l’extension et la fenêtre horaire à la personne qui gère l’hébergement. Donnez-lui un contrôle précis à faire : rechercher le code exact pour ce hook, puis vérifier si une prochaine occurrence apparaît après l’exécution. Santé du site peut aider à constater un problème plus large ; elle n’énumère pas les récurrences réellement chargées par ce traitement. Quand une extension propose son propre écran d’exécution, distinguez son historique métier des événements natifs de WP-Cron.

1. Sur la recette, notez le réglage existant. Appliquez seulement la mise à jour ou la correction documentée pour la tâche identifiée. Si la fonction a été volontairement retirée, ne la réactivez pas pour faire disparaître une ligne de journal.
2. Attendez le prochain passage normal du lanceur et vérifiez l’apparition du résultat de test. Contrôlez le passage suivant : une seule exécution réussie peut correspondre à l’ancien événement encore présent.
3. Si la trace se répète, revenez à la configuration précédente sur la copie et passez au contrôle du registre. Si vous avez remplacé un réglage, notez la valeur précédente et le moyen de la remettre. Évitez une restauration de base en bloc sur un site dont les données continuent à évoluer.

Contrôler la récurrence et l’événement via WP-CLI

Avec un accès SSH autorisé, vous pouvez lire séparément le registre des récurrences et la file. Choisissez le dossier WordPress de la recette et son URL ; sur un multisite, l’URL sélectionne le sous-site. N’ajoutez pas --skip-plugins pour simplifier la commande : vous pourriez retirer du diagnostic le composant qui fournit justement la fréquence. Le premier résultat doit vous dire si la clé cherchée existe et quel intervalle elle annonce. Le deuxième doit montrer si une occurrence de ce hook porte cette même clé, et quand elle est prévue en UTC.

L’exemple vise le hook et la clé mentionnés dans le forum. Remplacez le chemin, l’URL et le hook par vos valeurs. Les deux commandes ne lancent aucun événement et n’affichent pas les arguments. Plusieurs lignes du même hook peuvent correspondre à des tâches distinctes : si c’est le cas, ne concluez pas à un doublon. Une ligne sans récurrence peut être un événement unique voulu ; la replanification périodique concerne les événements qui portent une fréquence. S’il n’y a plus de ligne, la file a pu perdre l’occurrence à l’issue du dernier passage, ou l’extension a pu la retirer volontairement.

Si vous trouvez la clé en WP-CLI mais que le journal du worker HTTP dit l’inverse, comparez les contextes. Un filtre peut être chargé uniquement par une page d’administration, derrière un contrôle de capacité, ou dans une branche propre au terminal. Une commande réussie ne prouve pas que wp-cron.php a la même configuration. Vérifiez aussi si les deux accès utilisent la même installation et la même version du code. Si le problème vient d’un plugin tiers, n’ajoutez pas une fréquence sous son nom pour le faire taire : relevez le décalage, vérifiez la correction officielle et laissez le propriétaire décider de la fréquence et du traitement.

Un contrôle supplémentaire est utile en multisite : demandez pour quel domaine le passage est lancé et comparez la file de ce sous-site à celle où la tâche a été créée. La présence de la clé dans les récurrences d’un sous-site sain ne prouve rien pour celui qui émet l’erreur si l’activation ou les réglages diffèrent. Consignez séparément « clé vue en terminal », « clé chargée par le worker » et « nouvelle occurrence inscrite ». Si vous maintenez le code, vous pouvez ajouter en recette une trace qui indique seulement le contexte et la présence de la clé, puis retirer cette trace à la fin. Ce résultat évite de modifier le planificateur de l’hébergeur alors que le problème vient d’une condition de chargement.

wp --path="/chemin/recette" --url="https://recette.example.test" cron schedule list --fields=name,interval
wp --path="/chemin/recette" --url="https://recette.example.test" cron event list --hook=wsal_generate_reports_cron --fields=hook,schedule,interval,next_run_gmt

Essayer une récurrence dont vous maîtrisez le code

Utilisez cette approche si vous maintenez l’extension ou si vous devez prouver, sur une recette, que le même lanceur sait enchaîner deux occurrences d’une tâche à intervalle personnalisé. Le code enregistre une récurrence de dix minutes et une action témoin qui écrit une ligne dans le journal PHP. Il ne programme rien tout seul, n’envoie aucun rapport et n’intervient pas sur la tâche du forum. Le point utile est l’emplacement du filtre : à l’initialisation du fichier de l’extension, en dehors d’une page de réglages, avant les appels qui utilisent sa récurrence.

Sur la copie, créez wp-content/plugins/atelier-temoin-cron/atelier-temoin-cron.php dans le dossier des extensions de cette installation et collez le code. Activez « Atelier — témoin de récurrence » dans Extensions > Extensions installées. Confirmez que atelier_toutes_les_dix_minutes apparaît à 600 secondes dans la liste WP-CLI. Utilisez une seule fois, avec les mêmes paramètres de ciblage que plus haut, wp cron event schedule atelier_recette_temoin '+2 minutes' atelier_toutes_les_dix_minutes. Vérifiez que la liste filtrée pour atelier_recette_temoin montre une première échéance et l’intervalle attendu. Pour ce test, laissez le lanceur habituel de la recette effectuer le passage : une exécution manuelle ne démontre pas que le worker charge le filtre.

En règle générale, une tâche prévue pour une heure donnée n’est pas forcément exécutée à la seconde : la fréquence du lanceur doit être prise en compte. Utilisez une recette dont vous connaissez la cadence. Si le témoin ne démarre jamais, vérifiez le déclenchement avant d’accuser la récurrence. S’il écrit une ligne mais ne crée aucune échéance suivante, comparez le journal de cette occurrence au registre. À la fin, retirez d’abord cet événement de recette avec wp cron event delete atelier_recette_temoin sur la même cible, contrôlez que la liste filtrée est vide, puis désactivez et retirez l’extension témoin. Ne réutilisez pas ce nom de hook pour un traitement réel.

<?php
/**
 * Plugin Name: Atelier — témoin de récurrence
 */
if (!defined('ABSPATH')) {
    exit;
}

add_filter('cron_schedules', static function (array $schedules): array {
    $schedules['atelier_toutes_les_dix_minutes'] = [
        'interval' => 600,
        'display'  => 'Atelier : toutes les dix minutes',
    ];
    return $schedules;
});

add_action('atelier_recette_temoin', static function (): void {
    error_log('ATELIER-CRON : occurrence témoin exécutée');
});

Réparer le chargement de la fréquence ou retirer un ancien événement

Pour une extension que vous maintenez, retrouvez où son filtre est ajouté et où l’action est déclarée. Si le filtre est attaché seulement dans admin_init ou au moment d’afficher une page de paramètres, déplacez son enregistrement dans le chargement commun de l’extension. Conservez les autres clés reçues par le filtre. Utilisez un nom stable propre à cette extension. Si le code a renommé une ancienne clé, décidez d’une migration de l’événement : garder provisoirement l’ancienne clé avec le même intervalle peut convenir lorsque la tâche doit continuer, mais cela ne remplace pas une migration contrôlée quand la périodicité change.

Lorsque l’ancienne occurrence a déjà disparu, restaurer le filtre ne la recrée pas. Utilisez le mécanisme prévu par l’extension pour initialiser ou réactiver sa planification, après avoir vérifié qu’il n’existe pas déjà une occurrence pour cette tâche et ses arguments. Sur le code dont vous êtes propriétaire, comparez les arguments dans la recherche et dans l’inscription : un identifiant entier et le même identifiant en chaîne peuvent désigner deux entrées différentes pour WP-Cron. Recréer une seule ligne avec des arguments inventés risque de déclencher une autre opération ou de créer une nouvelle erreur.

Si la fonction a été retirée intentionnellement, le résultat attendu change : le hook ne doit plus être dans la file et rien ne doit produire son ancien résultat. Utilisez la procédure de nettoyage de l’extension ou demandez à son mainteneur d’identifier l’occurrence à retirer. Avant toute suppression d’un hook réel, vérifiez s’il porte plusieurs tâches et quels autres composants y sont abonnés. Ne supprimez pas une ligne du tableau cron dans la base à la main. Vider la file entière peut retirer des publications, des mises à jour et des opérations en attente qui n’ont aucun rapport avec la panne.

1. Notez la correction choisie : rétablir la clé, migrer une fréquence ou retirer une tâche désormais inutilisée. Sauvegardez la version du code ou la valeur du réglage qui permet un retour ciblé.
2. Rejouez le scénario sur une copie et comparez la file avant et après la première échéance. Si vous migrez l’événement, contrôlez qu’il n’existe qu’une occurrence pour la combinaison d’arguments voulue.
3. Vérifiez aussi la présence du traitement attendu. Une fréquence bien enregistrée peut planifier un hook dont le code métier est absent ; une file propre ne démontre pas qu’un rapport a été produit.

Vérifier deux échéances avant de clore le dépannage

Notez l’heure UTC du premier événement annoncé, puis l’heure réelle de la première exécution selon le journal ou le résultat métier. Relisez la file juste après : elle doit porter une échéance ultérieure avec la clé prévue. Refaites cette comparaison au passage suivant. Pour une tâche volontairement supprimée, la vérification consiste au contraire à constater l’absence de l’événement et de la trace associée, sans régression du témoin. Si la tâche s’exécute mais n’écrit pas le résultat attendu, ouvrez un diagnostic du callback, des droits ou des données dont il dépend.

Une ancienne erreur reste dans le journal après correction. Filtrez la période qui suit le changement et comparez le hook exact. La fin des erreurs seule ne suffit pas : si l’événement a disparu, le journal se tait aussi. La preuve utile associe une nouvelle échéance, un résultat métier et l’absence de nouvelle erreur pour la tâche maintenue. Si le témoin et le hook réel cessent ensemble, vérifiez le lanceur ou la cible d’hébergement. Si seul le hook réel échoue, remettez en recette le code ou le réglage précédent et communiquez au mainteneur les différences de récurrence et de contexte, sans journal brut contenant les arguments.

Pour reproduire le défaut sans données réelles, vous pouvez enlever le filtre de l’extension témoin sur une copie, en laissant le callback chargé. L’occurrence déjà enregistrée peut encore produire sa ligne, alors que la suivante n’est pas inscrite. Réinstallez le filtre, recréez une occurrence témoin si elle a disparu et répétez les deux passages. Ce contrôle différencie une absence de clé d’un arrêt complet du planificateur. Il ne prouve pas à lui seul l’origine de l’incident du forum : les extensions peuvent aussi remplacer les fonctions de planification ou modifier leur résultat.