[WordPress] Corriger le problème de planification d’articles (planification manquée)

Vous souhaitez prendre de l’avance dans votre planning en vous avançant dans vos brouillons, vous planifiez vos articles et autres backups et quelques jours plus tard… Vous vous apercevez qu’il n’y a rien eu du tout ! Votre WordPress ne sait plus planifier quoi que se soit, en vous affichant une erreur « Planification manquée » par exemple…

Cette mésaventure m’est arrivée depuis de nombreuses semaines sur ce site web, j’ai recherché un peu partout sur le web et demandé sur Twitter (vous vous reconnaîtrez ;)) si quelqu’un avait eu ce genre de problème – Des réponses et des pistes mais malheureusement aucune solution.

L’article ci-dessous a été effectué dans un serveur dédié – pour les connaisseurs, une infrastructure KVM dans Proxmox 4.4, sur une Debian 8.7 avec WordPress 4.7.2 et PHP 7.0.15 à l’heure de saisie.
Si vous utilisez un hébergement mutualisé, merci de vous référer au commentaire de « Darknote » (merci beaucoup !!)

Toutefois, voici les quelques pistes qui m’ont été donné :

  • Problème d’autorisation sur les dossiers / fichiers de WordPress
    Tout votre dossier WordPress (inclus les sous-dossiers et les fichiers) doivent être sous la propriété de l’utilisateur de votre serveur web, par exemple « www-data » pour Apache, « nginx » pour Nginx et non l’utilisateur « root ».
  • Problème de droits
    Faites attention au CHMOD sur certains fichiers – Vous pouvez effectuer un « sudo chmod -R 0755 /emplacement/wordpress/* » pour corriger ce problème
  • Utiliser une extension pour forcer la planification
    J’ai essayé plusieurs extensions pour WordPress, malheureusement aucune n’a fonctionné – de plus, ces extensions ne s’occupent que de la planification des articles, pas de la planification des backup ou autre.
  • Régler l’heure, la date et le fuseau horaire sur le serveur web
    Erreur qui arrive si l’on ne prend pas le temps de bien régler son serveur avant de le mettre en production – installez « ntp » sous Linux pour pouvoir synchroniser l’heure et la date sur le bon fuseau horaire et ce, de manière automatique. N’oubliez pas de lancer l’utilitaire au moins une fois pour effectuer la mise à jour de la date…
  • Régler l’heure, la date et le fuseau horaire dans WordPress
    Dans la partie « Réglages« , vous pouvez régler la date, l’heure et le fuseau horaire de votre site web – Utilisez strictement les mêmes paramètres que votre serveur web, sans quoi WordPress vous fera des misères…
  • Problème à cause d’une extension ou d’un thème
    Pour tous les tests, il est préférable de désactiver toutes les extensions ET tous les thèmes personnalisés.

La solution définitive

Enfin, il y a quelques jours, j’ai trouvé LA solution ultime pour corriger tous mes problèmes. Il s’agit d’un « hook » à effectuer dans le fichier « wp-config.php« .

Version courte

Ajoutez cette ligne de commande vers le milieu du fichier « wp-config.php », juste avant « /* bon blogging… */ » :

Redémarrez votre serveur web et le tour est joué !

Version longue

Si votre WordPress est « caché » derrière un routeur/pare-feu comme pfSense (plus d’informations à cette adresse), la planification manquée est dû non pas à un problème sur la machine en temps que telle, mais provient de l’architecture réseau – Oui, ça se corse…
En somme, si WordPress n’arrive pas à exécuter à temps le fichier « wp-cron.php » pour lancer les tâches planifiées, le site web effectuera une action via HTTP pour envoyer les commandes quant à la requête planifiée.

Mais (parce qu’il y a toujours un « mais » dans une problématique) comme votre WordPress est derrière un routeur/pare-feu et que celui-ci bloque les requêtes de loopback, votre site web WordPress ne pourra donc pas s’envoyer des requêtes sur lui-même, puisqu’elles sont bloquées par votre routeur/pare-feu (dans mon cas, pfSense), sécurité oblige…

C’est pour cette raison qu’il faut alors saisir la ligne de commande « define(‘ALTERNATE_WP_CRON’, true); » dans le fichier « wp-config.php » de votre site, pour retrouver enfin vos planifications comme auparavant.

J’ai actuellement cette solution sur CZS et je peux de nouveau effectuer mes planifications d’articles d’une part, mais aussi et surtout les tâches de sauvegarde !! Parce que oui, je ne pouvais plus sauvegarder le site à cause de cette histoire…

Solution trouvée sur le support WordPress (lien)


Note d’un lecteur :

L’utilisation de ce tweak ajoute des variables récupérables via « GET » dans votre barre d’adresse du navigateur. Pour affiner la sécurité, il est primordial de réécrire l’URL pour empêcher des attaques. Sous Apache2, voici ce que vous devez saisir dans le « .htaccess » dans le dossier racine de votre site web :

Merci ! 😉

Julien H

Passionné depuis toujours par l'informatique, je transforme ma passion en expertise. J'utilise quotidiennement les outils et systèmes Microsoft. Je ne délaisse pas mon côté ouvert, notamment via l'utilisation des OS Debian et Archlinux. L'infosec m'ouvre les yeux sur les enjeux actuels et futurs de l'IT.

12 Comments

  1. Bonjour,

    Vous dites « Redémarrez votre serveur web », comment on fait ça sur une offre mutualisé ?
    Cordialement

    1. Bonjour,
      Les serveurs mutualisés sont toujours un peu sensible pour pouvoir effectuer des manipulations – Il va falloir contacter le support technique / le prestataire de cet hébergement mutualisé pour soit faire redémarrer le service web ou alors voir avec lui pour planifier justement une intervention sur l’hébergement et redémarrer le serveur. Les droits sont limités en plus sur ces offres, il ne va pas être possible de faire un redémarrage soit-même.
      Bon courage !

        1. Malheureusement oui, je me suis basé sur un cas concret qui est tout simplement le mien 🙂 Je suis su r un serveur dédié (Online.NET).
          Ne perdez pas espoir en contactant le support tech auprès de votre hébergeur ! 🙂

      1. Bonjour,
        je ne perds pas espoir, je regrette juste que dans l’article, il ne soit pas précisé, pour serveur dédié.
        J’ai trouvé un complément d’information sur un article.

        Activer un cron externe à WordPress
        Deux cas de figure, selon que votre hébergeur propose ou non un service de planification de tâches.

        Exemple : OVH, 02switch…

        Dans ce cas, utilisez le planificateur de votre hébergeur pour déclencher les tâches de WordPress.

        Quel que soit votre hébergeur, il vous faudra deux informations : la fréquence et la commande à lancer.

        Fréquence

        La fréquence devra être ajustée à la tâche qui se produit le plus souvent, sachant que la fréquence ne peut pas être au-dessus de la minute. En général, un déclenchement toutes les heures devrait suffire.

        Les intervalles de temps par défaut de WordPress sont :

        toutes les heures (hourly)
        deux fois par jour (twicedaily)
        une fois par jour (daily)
        Note : OVH ne permet pas une fréquence supérieure à l’heure, tandis que chez o2switch elle peut aller jusqu’à la minute.
        Pour connaître la liste des tâches de votre site et leur fréquence, utilisez l’extension WP Crontrol ou Advanced Cron Manager – debug & control.
        Shell

        # +—————- minute (0 – 59)
        # | +————- heure (0 – 23)
        # | | +———- jour du mois (1 – 31)
        # | | | +——- mois (1 – 12)
        # | | | | +—- jour de la semaine (0 – 6) (dimanche=0)
        # | | | | |
        * * * * * commande à exécuter
        1
        2
        3
        4
        5
        6
        7
        # +—————- minute (0 – 59)
        # | +————- heure (0 – 23)
        # | | +———- jour du mois (1 – 31)
        # | | | +——- mois (1 – 12)
        # | | | | +—- jour de la semaine (0 – 6) (dimanche=0)
        # | | | | |
        * * * * * commande à exécuter
        Ce qui donne par exemple

        Quand Réglages
        Toutes les minutes * * * * *
        Toutes 15 minutes */15 * * * *
        A certaines minutes (1, 21…) 1/21/41 * * * *
        Toutes les heures 0 * * * *
        Commande

        Là aussi, deux possibilités :

        1 – Lancer le fichier avec PHP (méthode la plus sûre)

        Pour cela, il faut que le service de tâches planifiées soit exécuté sur le serveur où se trouve le fichier wp-cron.php.

        /usr/bin/php -f /chemin_complet/www/wp-cron.php

        Chez OVH faire pointer la tâche sur /répertoire_de_wordpress/wp-cron.php. OVH fourni un didacticiel pour configurer le système de tâches planifiées.
        Une image montre la procédure : http://hpics.li/2213b50

        Commande à lancer

        Note : certains disent que les droits du fichier wp-cron.php doivent le rendre exécutable 755, d’autres que ce n’est pas nécessaire 644. Pour ma part, j’ai opté pour 644. Testez.
        2 – Lancer le fichier avec une URL

        Cela permet de lancer la commande depuis un serveur qui n’est pas celui qui héberge le site.

        Le programme utilisé pour visiter l’URL peut être wget ou curl selon votre hébergeur ou le service de cron (voir la documentation de votre fournisseur). Il peut aussi masquer le service qui va accéder à l’URL (EasyCron). Dans ce cas, vous n’aurez qu’à fournir l’URL.

        0 * * * * wget -q -O – http://www.example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

        ou

        0 * * * * curl -s http://www.example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

        Le fichier wp-cron.php se trouve à la racine du site.

        Dans le cas d’un déclenchement par URL, l’appel au fichier wp-cron.php doit être suivi de ?doing_wp_cron.

        >/dev/null 2>&1 renvoi la sortie du script et le message de réussite (1) ou d’erreur (2) vers /dev/null, c’est-à-dire un trou noir.

        Attention : si vous utilisez iThemes Security, la liste noire de HackRepair.com bloque wget. Il faut alors utiliser curl ou retirer le blocage de wget dans le fichier .htaccess.
        Pour tester le fonctionnement du planificateur, commencez avec une commande simple : par exemple, envoyer un mail toutes les minutes ou écrire dans un fichier. Voici un exemple de script d’envoi de mail.

        https://openclassrooms.com/courses/e-mail-envoyer-un-e-mail-en-php

        Alors, ça fonctionne ?
        Pour voir si cela fonctionne, il faut attendre qu’un premier cycle se soit écoulé, vérifier que la prochaine tâche planifiée a bien été exécutée, puis regarder dans les logs de l’hébergeur si la tâche cron a été lancée.

        Cas particuliers
        Certaines extensions comme MailPoet proposent d’activer leur propre cron.

        Il semblerait que la mise en maintenance d’un site désactive le cron WordPress.

        1. En effet, ce n’était pas stipulé dans mon article, mea culpa. C’est désormais ajouté et mis à jour, merci 🙂
          Sacré réponse ! Il faut donc utiliser le planificateur de tâches de l’hébergeur et le prendre en main… Et là, bon courage – je ne sais pas du tout comment ces outils fonctionnent, je ne les ai jamais utilisé.

          1. Bonjour,
            bien votre rectification
            « L’article ci-dessous concerne une infrastructure sous KVM dans Proxmox, sur une Debian 8.6 avec WordPress 4.7 et PHP 7.0.11 à l’heure de saisie. »
            Mais le novice ne va pas comprendre que cela parle de Serveur Dédié,
            « L’article ci-dessous concerne une infrastructure de Serveur Dédié sous KVM dans Proxmox, sur une Debian 8.6 avec WordPress 4.7 et PHP 7.0.11 à l’heure de saisie. »
            Plus explicite comme ça.

            OVH a mis un tuto pour expliquer la procédure
            https://docs.ovh.com/fr/fr/web/hosting/mutualise-taches-automatisees-cron/

          2. Merci beaucoup pour les retours Darknote 🙂 C’est à l’instant modifié, de façon plus exhaustive.
            Je garde les liens dans mes favoris, c’est toujours utile !

  2. Le problème de cette méthode ALTERNATE_WP_CRON c’est qu’elle génère des paramètres dans l’URL : ?doing_wp_cron=[série de chiffres]

    1. En effet, ça fait une requête GET. Niveau sécurité, ce serait à tester – j’imagine quand même que les équipes de WordPress ont déjà réfléchi à ce problème 😉

      1. Il existe tout de même une méthode pour masquer ces paramètres. il suffit d’ajouter ceci au fichier .htaccess :

        Options +FollowSymLinks
        RewriteEngine On
        RewriteCond %{QUERY_STRING} (^|&)doing_wp_cron= [NC]
        RewriteRule (.*) /$1? [R=301,L]

        1. Super ! Merci beaucoup pour ton retour et cette solution !! J’ajoute dans l’article si tu me le permets 🙂
          Je ferai de même pour les utilisateurs nginx 😉

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. Apprenez comment vos données de commentaires sont traitées.

Close
Close