Les tâches cron de PrestaShop s'arrêtent en silence si vous renommez le dossier admin

Le symptôme : tout semble en ordre, et plus rien ne se passe

Aucune erreur nulle part dans le back-office. Aucun e-mail d'alerte. La boutique, une installation PrestaShop, était en ligne, vendait, répondait normalement. Le problème n'est apparu qu'en regardant une colonne que presque personne ne vérifie jamais : updated_at dans la table ps_cronjobs. Toutes les tâches planifiées du back-office, de la régénération du sitemap à la mise à jour de l'index de recherche, affichaient exactement la même date, figée depuis des semaines. Toutes les routines automatiques de la boutique s'étaient arrêtées au même moment, et personne ne l'avait remarqué, parce que s'arrêter en silence, c'est exactement ce que fait cette panne : il n'y a aucune erreur à regarder, seulement l'absence de quelque chose qui devrait se produire et ne se produit pas.

Ce que cela semblait être, et n'était pas

Une fois qu'on remarque que « quelque chose ne tourne plus », la tentation est de conclure trop vite que tout est cassé en même temps. Ce n'était pas le cas, et il vaut la peine de raconter ce qui a été vérifié et écarté avant d'arriver à la vraie cause :

• Les commandes d'un canal de vente externe semblaient bloquées elles aussi. Elles ne l'étaient pas : elles tournaient sur une ligne de crontab séparée, indépendante du planificateur de tâches de PrestaShop, qui n'avait jamais cessé de fonctionner. Le soupçon initial était faux parce qu'il regardait l'effet (moins de commandes sur cette période) au lieu de la cause.
• L'index de recherche interne semblait périmé. Il ne l'était pas : PrestaShop met à jour l'entrée d'index d'un produit au moment où le produit est enregistré, indépendamment du cron. La tâche planifiée « reconstruire l'index de recherche » n'est qu'un recalcul complet de maintenance, utile mais pas le seul moyen pour que les nouveaux produits deviennent trouvables. Vérifié par sondage : les produits ajoutés après l'arrêt du cron étaient déjà entièrement indexés.
• On pouvait penser à un problème de droits, ou au service cron du système d'exploitation. Écarté aussi : la crontab existait, la ligne était là, et elle ne produisait aucune erreur visible dans les logs du système. Le problème n'était pas que le cron ne tournait jamais : c'était que, quand il tournait, il n'obtenait pas ce qu'il attendait.

La vraie cause : le dossier /admin a changé, et personne n'a mis à jour ce qui l'appelle

Renommer le dossier admin de PrestaShop (de /admin en quelque chose d'imprévisible) est une recommandation de sécurité courante, que l'on retrouve dans pratiquement tous les guides de sécurisation d'une boutique PrestaShop. C'est aussi, presque toujours, un changement fait une fois puis oublié.

Or le mécanisme qui exécute les tâches planifiées de PrestaShop n'est normalement pas un processus interne qui tourne tout seul : c'est un appel HTTP planifié (un cron système, ou un service de planification externe) qui, toutes les heures ou à l'intervalle configuré, appelle une URL précise, du type :

0 * * * * curl -k \
  "https://store.example/
   admin<oldname>/index.php
   ?controller=AdminCronJobs
   &token=..."

Quand le dossier /admin<oldname> est renommé par sécurité, cet appel reçoit une 404. Le contrôleur AdminCronJobs n'est jamais invoqué, et aucune tâche planifiée ne s'exécute donc jamais. Il n'y a aucun message d'erreur nulle part, parce que du point de vue de PrestaShop, il ne s'est rien passé du tout : personne n'a jamais frappé à la bonne porte. La date à laquelle le dossier a été renommé et la date à laquelle les tâches ont cessé de se mettre à jour, une fois vérifiées, correspondaient exactement.

Le détail qui rend cette cause dangereuse, c'est justement que renommer le dossier admin est une bonne pratique de sécurité, pas une erreur. Personne ne fait instinctivement le lien avec « les tâches cron se sont arrêtées », parce que les deux semblent n'avoir rien en commun : l'un concerne la sécurité du back-office, l'autre l'automatisation en arrière-plan. Le lien n'existe que parce que le déclencheur du cron passe, techniquement, par la même adresse que le back-office.

Il y avait aussi un second problème, apparu seulement après avoir lancé à la main la tâche la plus importante pour confirmer que tout fonctionnait une fois l'adresse corrigée : le jeton de validation utilisé par l'URL de régénération du sitemap ne correspondait plus à ce qu'attendait le script. Même avec la bonne adresse, cette tâche aurait continué à répondre « jeton invalide » sans rien faire. Corriger uniquement le déclencheur ne suffit pas : il faut vérifier que chaque tâche, appelée à la main, répond réellement comme elle le doit, et pas seulement que la crontab pointe au bon endroit.

Le correctif

1. Mettre à jour la crontab avec le bon nom de dossier admin, après avoir sauvegardé la ligne précédente.
2. Corriger le jeton de la tâche précise qui était invalide, pour qu'elle recommence à tourner seule au prochain passage planifié.
3. Régénérer à la main le résultat bloqué, sans attendre la prochaine exécution automatique : dans le cas du sitemap, le fichier était figé depuis des semaines, et pendant ce temps les moteurs de recherche continuaient de lire un fichier qui disait « rien de nouveau ici ».
4. Vérifier aussi le contenu du fichier généré, et pas seulement son existence : le fichier d'index du sitemap portait une date de dernière modification vieille de plusieurs années, héritée de sa création, jamais mise à jour automatiquement à chaque régénération. Elle aussi a dû être corrigée à la main pour cesser de mentir aux moteurs de recherche.

Comment vérifier que le correctif tient

• Appelez l'URL correcte à la main et vérifiez qu'elle renvoie 200 avec le contenu attendu, sans vous arrêter à « la crontab est à jour ».
• ps_cronjobs.updated_at qui bouge vraiment, à la bonne heure. PrestaShop n'exécute chaque tâche que dans la plage horaire où elle est planifiée : une tâche prévue en pleine nuit ne s'exécutera pas si vous l'appelez l'après-midi. La bonne vérification n'est donc pas « j'ai appelé l'URL et ça a l'air de marcher », mais « le lendemain, à son heure prévue, cette tâche a réellement mis à jour sa propre date ».
• Vérifiez le résultat du point de vue de celui qui le consomme : pour un sitemap, cela veut dire le vérifier avec un simple navigateur (200) et, dans les logs du serveur, confirmer que le vrai robot du moteur de recherche le récupère effectivement avec succès, pas seulement que le fichier existe sur le disque.

La règle à retenir, valable pour toute boutique PrestaShop : si le dossier admin est de nouveau renommé à l'avenir, chaque endroit qui l'appelle depuis l'extérieur doit aussi être mis à jour, crontab comprise. Sinon, toutes les routines planifiées s'arrêtent à nouveau, en silence, et le premier signal arrive des mois plus tard, quand quelqu'un remarque par hasard une vieille date dans un panneau que personne ne regarde d'habitude.

Il vaut la peine de le dire honnêtement, parce que cela rend le problème plus crédible que n'importe quel chiffre : c'est arrivé à nous aussi, sur notre propre boutique. Les relances automatiques d'avis après un achat ne sont jamais parties, pour exactement la même raison de fond : il n'y avait pas de cron pour elles, et la bonne adresse à appeler n'était écrite nulle part jusqu'à ce que nous la corrigions. Ce n'est pas un cas isolé qui n'arrive qu'aux clients : c'est une erreur facile à faire pour quiconque gère une boutique PrestaShop, y compris celui qui écrit cet article.