OVH Community, votre nouvel espace communautaire.

HOW-TO : lancement des tâches planifiées Wordpress (wp-cron.php), Drupal 7, etc.


ddavid
03/07/2012, 16h10
Voici la méthode pour lancer les tâches cron Wordpress et Drupal 7 depuis le mutualisé, en programmant les tâches via le système de tâches planifiées OVH.

La méthode peut bien entendue être utilisée dans le cas d'autres CMS. La condition est que votre CMS ait une URL pour pouvoir lancer l'exécution des tâches planifiées.

Par défaut, Wordpress, Drupal 7 se basent sur les visites du site plus ou moins régulières pour lancer leur cron quand c'est utile.

Avantages d'utiliser la méthode par rapport au comportement par défaut :
* Cela peut rendre le CMS plus performant : après tout dépend comment le mécanisme par défaut est implémenté (sous wordpress, le serveur se fait une requête asynchrone vers lui même en parallèle à la visite, les tâches du cron wordpress ne ralentissent pas ainsi le chargement par le visiteur ayant déclenché le cron).
* La vérification de la nécessité d'exécuter cron lors des visites ne peut se faire que si le code PHP des CMS est exécuté. Hors quand on utilise un système de cache basé sur des fichiers statiques et mod_rewrite (ça peut être le cas avec certains réglages de WP Super Cache notamment, ainsi qu'avec d'autres systèmes similaires), il se peut que le contenu soit délivré directement sans exécuter le code de vérification du cron présent dans le CMS. NB : Les systèmes de cache basé sur du mod_rewrite ont par ailleurs très souvent besoin que le cron tourne régulièrement pour pouvoir nettoyer le cache en enlevant le contenu expiré...
* Et j'en passe...

Principe de la méthode utilisée (en bref) : on planifie l'exécution de wget en indiquant pour cible l'URL qui déclenche le cron.

Méthode :
1) On détermine l'URL qui déclenche le cron. Attention on parle bien de l'URL et non du chemin dans le système de fichiers sur le serveur mutualisé.
1.a. Pour Wordpress : on prend l'URL de la racine du blog et l'on rajoute "wp-cron.php" au bout. Par exemple : "http://www.example.com/wp-cron.php" ou "http://www.example.org/chemin/de/wordpress/wp-cron.php".
1.b. Pour Drupal 7, il vous faut récupérer l'URL du cron.php via le "status report". En effet, l'URL contient une clé en paramètre.
2) On crée un dossier "scripts" en dehors du "www" (dans le dossier qui contient "www").
3) On crée au même niveau un dossier logs-scripts
4) On adapte et l'on dépose le script wgetcron.sh dont le code suit.
5) On lui donne la permission d'exécution (chmod a+x nomdefichier en ssh, ou ajout via le client FTP).
6) On planifie le script dans le planificateur :
* script à exécuter "scripts/wgetcron.sh"
* langage : autre
* description (c'est pour vous retrouver) : wgetcron + nom de la cible
* logs par emails : avez-vous envie de recevoir un email à chaque exécution ? (sauf si vous utilisez des filtres ou une boîte à usage spécifique, ça risque d'être non...)
* jour : tous
* heures : à vous de voir : toutes les heures, deux heures, trois heures... Je pense qu'une fois par heure est bien pour ce type de tâche.
7) On vérifie les deux types de logs dipsonibles : ceux Apache (sur la cible), ainsi que le fichier dans le dossier ~/logs-scripts.
8) Si tout est OK, on règle le CMS pour que le système "archaïque" de cron lors des visites soit désactivé. Si vous modifiez un fichier de config, attention à ce qu'une sauvegarde ne soit pas présente sur l'hébergement avec une autre extension (il pourrait ne pas être interprété, auquel cas un attaquant pourrait en profiter)
8.a. Pour Wordpress : dans le wp-config.php : "define('DISABLE_WP_CRON', true);"
8.b. Pour Drupal 7, on passe la fréquence de vérification sur "never".

Voici le code de wgetcron.sh (très simple) :
Code:
#!/bin/bash
ERRLOG=~/logs-scripts/wgetcron.log
TARGET=http://www.example.org/wp-cron.php # Adapter selon étape 1 (1a ou 1b ou autre selon CMS)
UA=WgetCron-ViaPlanficateursTachesOVH # Adapter pour que ça passe à travers tout filtrage .htaccess, mais aussi pour que vous soyez sûr que la requête provient bien de votre exécution de script...
wget -nv -U $UA -O /dev/null $TARGET >/dev/null 2>>$ERRLOG
Rappel : attention aux permissions.

Vous pouvez créer des copies de ce scripts avec différents noms, pour en avoir un pour chaque URL différente correspondant à un cron de CMS que vous voulez lancer.

Pièges :
* Pas la peine de tester le script en se connectant en ssh au serveur mutualisé. Ça risque de ne pas marcher. Planifiez pour dès que possible et vérifiez le résultat, via les logs générés par le script, et via les logs d'accès générés par Apache. La machine sur laquelle on se connecte en ssh interdit toute connexion sortante et tout wget...
* Le script dépend des DNS pour déterminer la cible de la requête. Si vous migrez votre CMS du mutualisé ovh vers autre chose, il suffit que les DNS soient mis à jour pour que votre script aille taper sur votre nouvelle installation. Si vous installez un CMS sur le mutu pour des tests et que les DNS ne sont pas réglés (par exemple si vous comptez sur un fichier hosts), alors ce script ne pourra pas fonctionner.

Et pour ceux qui seraient tenter de lancer directement un script php via le système de planification (sans utiliser cette méthode donc) :
* Si vous lancez directement le binaire php, en indiquant en paramètre le chemin du fichier de cron de votre CMS, alors tous les réglages du .htaccess seront ignorés, et en plus de faire attention à utiliser le chemin de la bonne version de PHP, il vous faudra vous arranger pour passer en paramètre le chemin du bon php.ini (/usr/local/lib/php.ini-3 peut être ?). Pour être sûr de lancer le script avec la même config, autant être sûr que le cron soit executé via Apache.
* Si vous exécutez un fichier php qui effectue uniquement une requête HTTP vers l'URL de votre cron, alors vous pouvez obtenir l'équivalent de ce que fait le script ci-dessus. C'est pas spécialement plus simple. Utilisez alors de préférence ignore_user_abort avant de lancer la requête, ou prenez autrement vos précautions pour que ça se passe bien...