Confirmer le document avant toute relance
La date prévue est passée et WordPress indique une publication manquée pour votre article. Vous voulez rendre disponible le bon texte, une seule fois, ou reporter sa sortie selon une nouvelle décision éditoriale. Le premier réflexe consiste à confirmer son état réel avant de cliquer de nouveau sur Publier.
Si le document ne doit plus sortir, faites annuler sa programmation par une personne autorisée et conservez-le en brouillon. Le diagnostic ne doit pas devenir une attente pendant laquelle un contenu périmé pourrait être publié. Des visites et certains chargements de WordPress peuvent donner une nouvelle occasion d’exécuter une tâche arrivée à échéance.
Retrouvez l’original dans Articles et relevez son titre, son identifiant si disponible, sa date prévue et son état actuel. Comparez le lien de consultation avec un aperçu de rédaction : ils n’ont pas le même rôle. Si le document est déjà publié mais manque uniquement dans la liste du blog, le problème concerne plutôt cette liste.
Ne créez pas immédiatement un duplicata pour contourner le retard. L’original peut encore devenir public, tandis que la copie possède sa propre adresse et ses propres effets de publication. Gardez le contenu et les réglages initiaux pour décider d’une reprise ciblée.
Comparer l’heure attendue et l’état enregistré
Ouvrez les réglages de l’article avec un compte autorisé. Vérifiez la date complète, l’heure et le statut conservés après enregistrement. Un document resté en brouillon ou en attente de relecture n’est pas un article effectivement programmé. Le choix d’une date future doit être confirmé par l’action de programmation et par l’état affiché ensuite.
Avec les droits nécessaires, consultez Réglages, Général pour relever le fuseau du site. Comparez les deux heures dans ce même repère. Une heure locale sur votre ordinateur et une date exprimée en UTC ne doivent pas être comparées directement. Si l’échéance n’est pas encore atteinte dans le repère du site, il n’y a peut-être pas de publication manquée à réparer.
Ne changez pas le fuseau global pour faire coïncider cet article avec votre attente. Ce réglage concerne aussi les autres programmations et affichages. Une correction de fuseau doit être préparée séparément, avec la personne responsable du calendrier éditorial.
Vérifiez enfin la visibilité. Un document réservé ne devient pas nécessairement consultable par tous parce que sa date est passée. Gardez sa protection prévue et distinguez un accès refusé d’un article qui n’a pas changé d’état.
Interpréter la date UTC avant de chercher un retard
Écrivez l’échéance attendue sous une forme que l’équipe peut relire. « 15 juillet 2027, 9 h à Paris » devient « 15 juillet 2027, 7 h UTC ». Le même 15 juillet à 9 h dans un site réglé sur UTC correspond à 11 h à Paris. Si l’article porte 9 h UTC et que la personne chargée de vérifier se présente à 9 h à Paris, deux heures restent à courir. L’événement peut être parfaitement cohérent avec la date enregistrée tout en s’écartant du calendrier éditorial. En hiver, Paris passe à un autre décalage. Convertissez la date précise avec un fuseau nommé, sans reprendre le décalage du jour de votre vérification.
Sur un WordPress avec accès technique, relevez ensemble post_date (heure civile enregistrée), post_date_gmt (échéance UTC enregistrée) et l’instant UTC de l’événement natif publish_future_post. Les deux derniers peuvent se comparer directement. Si le site a changé de fuseau après la programmation, gardez la date locale comme trace de ce que le document contient et confrontez la date UTC à l’intention d’origine. Un réglage de fuseau actuel peut expliquer comment une nouvelle date serait enregistrée. Il ne prouve pas comment un document ancien a été enregistré.
Si votre annonce doit sortir à une heure précise, faites confirmer le fuseau par la personne qui valide le calendrier. Lors d’un changement d’heure, une heure locale peut manquer ou se produire deux fois. Pour une échéance de ce type, utilisez un créneau sans ambiguïté si l’équipe le permet, ou faites confirmer l’instant UTC et comparez-le après enregistrement. Si la date est déjà passée et que la sortie n’est plus souhaitée, choisissez d’abord le brouillon comme indiqué plus haut.
Lire l’événement exact sans exécuter de tâche
Cette lecture convient à un responsable disposant de WP-CLI. Enregistrez le code de cette section sous verifier-programmation.php, dans un dossier privé hors du répertoire public. Placez-vous dans le dossier WordPress et lancez wp --url=https://exemple.test eval-file /chemin/prive/verifier-programmation.php 123. Remplacez l’URL par celle du site concerné, notamment en multisite, et 123 par l’identifiant de l’article, visible par exemple dans l’adresse de son écran de modification. Une installation non accessible par ce moyen se vérifie à partir de l’éditeur et des relevés transmis par son responsable.
Le script charge WordPress pour lire le document et la prochaine occurrence du hook avec cet identifiant comme seul argument. Il n’appelle aucune fonction de publication ou d’exécution de la file. Faites la lecture avant toute correction et conservez le résultat avec l’heure du constat. Si la date UTC est absente, le script renvoie null. Si aucun événement correspondant n’est trouvé, evenement_utc vaut null même si le site a des tâches en attente pour d’autres articles. Si l’article passe à Publié entre deux lectures, vérifiez son adresse et sa visibilité avant d’envisager une reprise.
<?php
$id = filter_var($args[0] ?? null, FILTER_VALIDATE_INT, [
'options' => ['min_range' => 1],
]);
$article = $id ? get_post($id) : null;
if (!$article || $article->post_type !== 'post') {
WP_CLI::error('Identifiant d’article introuvable sur ce site.');
}
$utc = new DateTimeZone('UTC');
$date = $article->post_date_gmt;
$instant = $date !== '0000-00-00 00:00:00'
? DateTimeImmutable::createFromFormat('!Y-m-d H:i:s', $date, $utc)
: false;
$evenement = wp_get_scheduled_event('publish_future_post', [$id]);
echo wp_json_encode([
'id' => $id,
'statut' => $article->post_status,
'fuseau_site' => wp_timezone_string(),
'date_locale_enregistree' => $article->post_date,
'date_utc_enregistree' => $instant ? $instant->format(DATE_ATOM) : null,
'maintenant_utc' => gmdate(DATE_ATOM),
'evenement_utc' => $evenement ? gmdate(DATE_ATOM, $evenement->timestamp) : null,
], JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES) . PHP_EOL;Choisir la correction à partir du relevé
Pour un article encore future, commencez par comparer la date UTC enregistrée à l’échéance voulue. Si elle diffère, reprogrammez l’original à l’heure correcte lorsque celle-ci reste à venir et que la nouvelle échéance est autorisée. Rouvrez l’éditeur puis relisez le résultat. Vous devez retrouver le même identifiant, le statut Programmé et un événement à l’instant UTC convenu. Si l’heure souhaitée est passée, choisissez entre les parcours de publication immédiate, de report ou de maintien en brouillon.
Si la date UTC est correcte, passée, et que l’événement correspondant est lui aussi échu, le travail figure encore dans la file au moment du relevé. Consultez les journaux du déclencheur utilisé par ce site autour de cette heure et voyez si d’autres événements natifs sont arrivés à échéance. Relevez si un passage du worker a réellement abouti. Une entrée encore présente ne permet pas de départager une absence de déclenchement, un démarrage qui n’a pas abouti ou un traitement en cours. Si les deux horodatages sont différents, gardez-les tous les deux. Le callback natif vérifie la date UTC du document et peut replanifier un événement qui s’exécute trop tôt.
Si la date correcte est passée et qu’aucun événement ne correspond, refaites une lecture après avoir confirmé que l’article est toujours programmé. Pour une sortie reportée et autorisée, enregistrez une nouvelle échéance future assez éloignée pour pouvoir la contrôler. Vérifiez que WordPress propose bien de programmer, puis comparez les deux instants après l’enregistrement. Si l’événement est encore absent ou divergent, conservez l’identifiant, les deux dates et l’erreur éventuelle dans les journaux d’enregistrement. Une relance générale du planificateur ne recrée pas, à elle seule, l’occurrence manquante de cet article.
Observer la file depuis le tableau de bord
Quand l’administration est accessible mais que WP-CLI ne l’est pas, WP Crontrol permet d’observer la file sur une copie ou dans un environnement où son installation est déjà autorisée. Ouvrez Cron → Événements cron (ou Outils → Événements cron selon la version), recherchez publish_future_post et vérifiez l’identifiant dans les arguments. Comparez ensuite la prochaine exécution à la date prévue en tenant compte du fuseau affiché. La présence du même nom pour un autre article ne confirme rien pour le vôtre.
Pour ce diagnostic, contentez-vous de lire la liste. Les commandes d’exécution, de modification et de pause agissent sur la file. Le test du guide utilise le planificateur natif. Si le document est prêt et que la publication immédiate est autorisée, passez par l’éditeur de l’article pour garder la décision dans le flux éditorial habituel.
Préserver les effets prévus et choisir une reprise
Relisez le texte avant une sortie tardive : une annonce, une promotion ou une information à échéance peut nécessiter une décision éditoriale nouvelle. Faites confirmer si l’article doit paraître maintenant, attendre une autre date ou rester en brouillon. Le dépannage technique ne choisit pas à lui seul le moment approprié.
Relevez les effets associés déjà configurés : notifications, lettre d’information, diffusion externe ou autre automatisation. Une publication peut les déclencher. Vérifiez les journaux disponibles et ce qui a réellement eu lieu, sans envoyer de nouveaux messages pour tester. Sur WordPress.com, la publication d’un article programmé peut notifier les abonnés.
Le premier parcours convient à un document isolé, prêt et autorisé à sortir immédiatement. Le deuxième prépare une nouvelle échéance lorsque la publication doit rester différée. Le troisième sert aux échecs répétés ou aux indices d’un problème de tâches de fond ; il ne consiste pas à relancer toute la file.
Conservez une copie du texte et les valeurs de date, statut et visibilité avant une modification. Pour une intervention sur la configuration ou les composants, prévoyez une sauvegarde récupérable et une copie isolée. En multisite, confirmez le sous-site ; sur WordPress.com, utilisez les accès réellement disponibles plutôt qu’un parcours d’hébergement supposé.
Approche 1 : publier maintenant un article prêt
Cette reprise demande le droit de publier le document et une décision explicite de sortie immédiate. Ouvrez l’original, vérifiez qu’aucun collègue n’est en train de le corriger et relisez son contenu final. Ne republiez pas une copie dont vous ne connaissez pas la relation avec l’article programmé.
Dans les réglages de publication, ouvrez le calendrier et choisissez Maintenant ou la date et l’heure actuelles selon l’interface. Vérifiez que l’action proposée correspond à une publication immédiate, puis confirmez-la une seule fois après contrôle du récapitulatif. Les libellés peuvent varier entre l’éditeur de blocs et le panneau de publication classique.
Si vous voulez conserver une date antérieure pour une raison éditoriale, faites valider ce choix séparément. Il peut influencer le classement du document et, lorsque l’adresse contient la date, son lien. Ne décalez pas plusieurs fois l’horodatage uniquement pour faire disparaître l’avertissement.
Attendez la réponse de l’éditeur puis rouvrez l’état enregistré. Le résultat attendu est Publié pour le document voulu. Si le bouton paraît sans effet ou qu’une erreur apparaît, conservez le message et vérifiez l’état avant toute deuxième tentative. Une absence de retour visuel ne garantit pas que la première action n’a rien effectué.
Vérifier la sortie sans répéter les effets externes
Ouvrez le lien public dans une session adaptée à la visibilité prévue. Contrôlez le titre, le contenu et l’adresse. Vérifiez ensuite sa présence dans la liste attendue, en tenant compte du tri et de la date conservée. Un lien direct fonctionnel et une absence du blog désignent un problème différent de la programmation.
Consultez les traces des notifications ou diffusions déjà configurées, si votre compte peut y accéder. Leur fonctionnement dépend du service installé ; la réussite de publication du texte ne prouve pas que chaque service externe a terminé. Inversement, l’absence d’un message dans votre boîte ne prouve pas qu’aucun destinataire ne l’a reçu.
Ne remettez pas l’article en brouillon puis en publication pour forcer un nouvel envoi. Ne créez pas non plus une copie publique uniquement pour déclencher une notification. Faites examiner l’effet manquant par le responsable du service, à partir de l’identifiant du document et de l’heure de la sortie réelle.
Si la publication doit être retirée après coup, une personne autorisée peut modifier son état selon la décision éditoriale. Ce retrait n’annule pas un courriel déjà envoyé, une consultation ou une diffusion externe. Prévenez le responsable de ces effets plutôt que de présenter le retour en brouillon comme une annulation complète de l’opération.
Approche 2 : préparer une nouvelle échéance
Si l’article ne doit pas paraître maintenant, préparez son report sur l’original après avoir confirmé qu’il n’est pas déjà publié. Choisissez une date future cohérente avec le fuseau du site, lisez le récapitulatif et validez Programmer. Rouvrez ensuite ses réglages pour vérifier la date et l’état réellement conservés.
Un déplacement de date est une nouvelle décision de calendrier. Il ne répare pas automatiquement le mécanisme qui a manqué la première échéance. Si plusieurs programmations ont déjà échoué, examinez le déclenchement avec le responsable avant de compter sur ce seul report pour une annonce urgente.
Gardez la date initiale dans votre relevé de suivi et notez la nouvelle consigne. Vérifiez les liens déjà préparés dans les communications externes, surtout si leur structure contient la date. Ne promettez pas que l’adresse restera identique dans toutes les configurations ; comparez celle que fournit désormais WordPress.
Si vous annulez ce report, revenez au choix éditorial validé : brouillon ou nouvelle échéance précise. Ne rétablissez pas mécaniquement une ancienne date dépassée, car elle pourrait rendre le document immédiatement publiable lors d’un prochain déclenchement. Vérifiez l’état final et informez les autres auteurs du calendrier retenu.
Comprendre ce que le retard indique sur WP-Cron
WP-Cron est le mécanisme qui permet à WordPress de traiter des tâches arrivées à échéance, dont la publication programmée. Dans son fonctionnement habituel, des chargements de WordPress lui donnent une occasion de démarrer. Il ne s’agit pas d’une horloge qui exécute nécessairement le travail à la seconde prévue.
Un site peu sollicité peut donc publier plus tard que l’heure demandée. Cependant, le nombre de visites affiché dans les statistiques ne prouve pas que le mécanisme a été correctement lancé. Un appel interne peut échouer, un environnement géré peut utiliser un autre déclenchement et la fonction chargée du document peut rencontrer une erreur.
La publication programmée native vérifie notamment que le document existe encore, qu’il reste dans l’état programmé et que son échéance est atteinte. Le responsable technique doit donc rapprocher l’événement et le bon article. Une tâche générale visible dans un outil ne démontre pas que ce document précis a été traité.
Ne rechargez pas continuellement le site pour tenter de forcer le rattrapage. Une visite peut coïncider avec la sortie attendue sans expliquer le blocage initial. Si plusieurs articles ont manqué leur échéance, conservez cette répétition comme un indice et passez au diagnostic du déclenchement.
Approche 3 : relever une panne répétée sans lancer toute la file
Avec un compte autorisé, ouvrez Outils, Santé du site et consultez l’onglet État. Relevez les avertissements concernant les événements planifiés et les requêtes de bouclage. Une requête de bouclage est une demande envoyée par le serveur vers son propre site ; WordPress l’utilise notamment pour démarrer WP-Cron.
Gardez le texte exact du message et l’heure du contrôle. Comparez avec d’autres articles récemment programmés : tous échouent-ils, ou seulement un document ? Évitez un relevé contenant le texte confidentiel d’articles encore inédits. Les titres et identifiants utiles doivent rester dans le canal de support adapté.
Le résultat de Santé du site est un indice, pas la preuve de publication de chaque article. S’il signale un problème, transmettez-le au responsable technique. S’il ne signale rien mais que le même retard se répète, gardez vos exemples et demandez un rapprochement avec les journaux à leurs heures prévues.
Ne cliquez pas sur une commande destinée à lancer tous les événements échus. Le site peut héberger d’autres tâches avec des effets externes. Cette phase cherche à identifier le mécanisme concerné ; elle n’a pas besoin d’effacer une file, de supprimer un événement ni d’installer une extension de rattrapage.
Faire vérifier le bon environnement par son responsable
Transmettez au responsable du site ou à l’hébergeur l’identifiant de l’article, son état, la date prévue avec son fuseau et les avertissements relevés. Demandez de vérifier le déclenchement réellement utilisé et son lien avec l’installation actuelle. Après une migration, un ancien chemin ou un domaine de copie peut être resté dans une configuration externe.
Une planification serveur peut être volontaire et remplacer le déclenchement habituel. N’ajoutez pas une deuxième tâche et ne changez pas une constante de configuration avant d’avoir confirmé l’organisation existante. Le diagnostic technique détaillé des tâches de fond reste distinct de la reprise éditoriale de cet article.
Sur WordPress.com, faites confirmer les possibilités réelles par le support si vous ne disposez pas des accès correspondants. En multisite, indiquez le sous-site touché ; la réussite du site principal ne suffit pas à valider toute la programmation du réseau.
Si une extension intervient dans la publication, identifiez-la à partir des journaux et de sa documentation. Une correction de composant se prépare sur copie sauvegardée avec ses effets externes neutralisés. Ne désactivez pas globalement la sécurité ou toutes les extensions sur le site public pour faire disparaître le message de publication manquée.
Préparer une vérification de programmation adaptée
Après une correction technique, convenez avec le responsable d’un contrôle limité. Sur une copie isolée, utilisez un document d’essai sans contenu confidentiel et une échéance proche mais clairement future dans le fuseau vérifié. La copie doit être préparée avant cet essai pour ne pas envoyer de courriels, déclencher de diffusion ou agir sur des services réels.
Notez l’état après programmation, la date prévue et le résultat après l’échéance. Vérifiez que le document change effectivement d’état et que sa page se consulte dans l’environnement de test. La simple disparition d’un avertissement de Santé du site ne démontre pas ce résultat.
Un essai réussi sur copie ne valide pas à lui seul le planificateur du site actif : son adresse, ses protections et son trafic peuvent différer. Pour la production, observez la prochaine publication légitime prévue avec l’équipe plutôt que de créer une annonce publique factice. Gardez un moyen de contrôle éditorial si son heure est importante.
Ne déduisez pas d’un seul succès une garantie à la seconde. Faites préciser au responsable le mécanisme et la précision attendue. Si l’échéance exige une intervention humaine de secours, préparez-la comme une décision de publication contrôlée, sans ajouter un second déclenchement automatique dont personne ne suivrait les effets.
Reproduire le retard et vérifier la reprise sur une copie isolée
Le témoin de ce guide a utilisé WordPress 7.1.4 avec le déclenchement automatique désactivé sur une installation jetable. Deux articles fictifs ont été programmés à la même échéance, un peu plus d’une minute à l’avance. Sur la copie uniquement, le test a retiré l’événement du second article avec wp_clear_scheduled_hook('publish_future_post', [$id]). Un appel anticipé au callback pour le premier article l’a laissé programmé avec la même échéance. Le test a attendu que l’heure soit réellement passée. Les deux articles étaient encore future, avec un événement échu pour le premier et aucun événement pour le second.
Le worker natif a ensuite été exécuté une fois sur la copie. Seul le premier article est passé à publish et son événement a disparu de la file. Le second est resté future. Après enregistrement d’une nouvelle échéance future sur ce second article, WordPress a créé l’événement pour le même identifiant. Dans un essai séparé, deux articles saisis à 9 h le même jour de juillet ont donné 7 h et 9 h UTC. La même copie avait été réglée d’abord sur Europe/Paris, puis sur UTC. Dans les deux cas, l’événement correspondait à l’instant enregistré.
Pour refaire cette vérification après une intervention, commencez par un seul article fictif sur votre copie, avec les courriels et diffusions externes neutralisés. Laissez plusieurs minutes pour relever l’état avant l’échéance, puis vérifiez l’état après le prochain passage attendu du déclencheur. Comparez aussi l’accès à l’URL dans une fenêtre anonyme de la copie si l’article est censé être public. Si vous voulez reproduire l’absence d’événement, réservez le retrait ciblé à un second témoin jetable. Supprimez les témoins à la fin et remettez la configuration initiale de la copie. Sur le site actif, le contrôle reste celui de la prochaine publication légitime et du déclencheur réellement en service.
Contrôler les autres articles encore programmés
Revenez à la liste des articles avec un compte habilité et repérez les documents programmés concernés par la même période. Comparez leurs dates, états et décisions éditoriales. Ne les publiez pas en groupe uniquement parce qu’un premier article a manqué son heure ; certains peuvent encore attendre leur échéance normale.
Pour les contenus dépassés, faites confirmer séparément maintien, report ou annulation. Une reprise technique de WP-Cron peut donner une nouvelle occasion de traiter les échéances anciennes. L’équipe doit donc savoir quels documents sont toujours autorisés à sortir avant de remettre le mécanisme en fonctionnement régulier.
Vérifiez aussi les liens de communication déjà préparés et le résultat dans le blog. Si une date modifiée place l’article plus loin dans la liste, ne la changez pas encore pour le faire remonter sans décision. Le diagnostic d’affichage suit celui de l’état ; il ne remplace pas le contrôle de la programmation.
Gardez un relevé court des cas confirmés, avec l’heure prévue et l’heure de publication observée lorsqu’elle est connue. Distinguez cette observation de l’heure affichée dans le document, qui peut avoir été conservée ou ajustée. Ne fabriquez pas une heure réelle d’exécution à partir de la seule date éditoriale.
Documenter la reprise et ses limites d’annulation
Consignez l’état initial, la décision retenue et l’action effectuée : publication immédiate, nouvelle programmation ou maintien en brouillon. Ajoutez la correction technique si elle a été démontrée, ainsi que le contrôle restant à effectuer. Une publication manuelle réussie résout la sortie de cet article ; elle ne démontre pas que les prochaines programmations fonctionneront.
Pour annuler un réglage de configuration, faites rétablir la valeur précise conservée avec le responsable. Ne restaurez pas toute la base pour revenir sur une date : vous pourriez perdre des articles et modifications plus récents. Pour un document encore inédit, vérifiez le statut final choisi plutôt que de remettre une ancienne échéance sans la relire.
Si l’article est devenu public, son retrait relève d’une nouvelle décision dont les effets externes doivent être examinés. Contrôlez les diffusions déjà faites et les liens partagés avec l’équipe concernée. Aucun retour de statut dans WordPress ne rappelle automatiquement les informations déjà consultées ou envoyées ailleurs.
Si le problème revient, transmettez les exemples datés et le dernier résultat connu au support. Gardez l’identifiant de l’article et les messages techniques dans un espace adapté, sans texte inédit ni secret inutile. L’objectif est une cause vérifiable et un calendrier de nouveau fiable, pas une série de duplications qui masque les retards.
