Bonjour à tous,
Le contexte :
Je dois réaliser un script PHP intégré à Drupal, qui fait les choses suivantes :
-
Parcours d’une arborescence placée à la racine de mon site (par exemple)
-
Recherche dans cette arborescence de fichiers XML, ouverture, et parsage de ces fichiers XML
-
Selon les données récupérées, je dois comparer les valeurs du XML avec des données stockées dans une table de Drupal, après comparaison je dois faire des traitements (insertion/modification/suppression de données dans la table)
-
Executer ce script quotidiennement (CRON)
-
La table interrogée est une table issue de la création d’un type de contenu créé via CCK
-
Le script doit (ou pourrait ?) être intégré à un module, en vue d’être activé ou désactivé depuis le back office.
Etat des lieux :
-
Le script PHP est créé, le parsage des fichiers XML est OK
-
J’ai créé un début de module Drupal dans lequel j’arrive à insérer des jeux de données dans ma table issue de CCK (node_save…), par contre en l’état le script du module s’execute au chargement de n’importe quel page…
-
J’exploite aussi l’api (node_load) pour lire des entrées de la table en vue de réaliser les comparaisons
-
Je suis grand débutant sur Drupal !
Questions :
-
Comment déclencher ce script PHP/Drupal ?
-
La création d’un module est-elle la solution à retenir ?
-
Faudrait-il exploiter les actions de Drupal ?
-
Un script PHP intégré à un module peut-il être exécuté via CRON
Si vous pouviez m’aiguiller sur l’architecture à retenir pour intégrer un tel script, je vous en serais très reconnaissant.
Merci !
- Vous devez vous identifier ou créer un compte pour écrire des commentaires
La création d’un module est-elle la solution à retenir ?
oui. Tu as évidement la possibilité de créer un script php à la racine de Drupal et booter drupal à la main comme le fait l’index.php de Drupal, mais en général avec cette approche, tu fais l’impasse sur la sécurité 1/ parce que tu ne vérifie que rarement les droits de l’utilisateur-lanceur 2/ tu augments le nombre de «porte» de drupal et donc tu augmentes de manière statistique le nombre de failles.
Faudrait-il exploiter les actions de Drupal ?
Les hooks tu veux dire. En fait seul toi peut répondre à cette question. Est-ce que ton script pourrait faire l’économie d’un lancement global chaque nuits s’il était au courant de la création/modification d’un node, d’un commentaire, etc. Si la réponse est oui, tu oublies la suite de ce post et effectivement tu fais un module implémentant hook_comment, hook_user ou autre hook_nodeapi et tu fonctionnes en événementiel. Sinon, faut rester monolithique.
Comment déclencher ce script PHP/Drupal ?
A vue de nez je vois trois approches (propres ;-).
La première consiste à utiliser le hook_cron mais cela va t’obliger à vérifier l’heure pour te lancer car le cron de drupal est généralement exécuté à une fréquence élevé (1/4 d’heure) par rapport à ton besoin.
La seconde est de dédier une URL pour ton script (ex /scripts/mon_script) par le biais d’un hook_menu. Simple et rapide tu peux gérer les droits facilement et lier le chemin à une simple fonction PHP qui va lancer (ou être) ton script.
La troisième consiste à utiliser l’outil drush et d’écrire une commande pour celui-ci. Ce serait mon option de choix car 1/ tu peux travailler avec le niveau utilisateur désiré 2/ tu n’as aucun risque de sécurité car la commande drush n’est pas accessible via le web 3/ tu peux lancer ton script à la main ce qui peut être utile 4/ Drush est maintenant inclus dans beaucoup de distributions (ex. debian).
Un script PHP intégré à un module peut-il être exécuté via CRON
Oui toujours. Dans le cas de hook_cron et hook_menu tu passes simplement par des commandes comme wget. Se posent en revanche le problème de scripts qui ont besoin de droits administrateur qui peuvent t’obliger à rajouter un mot de passe en paramétre à ton script et une escalade sur l’uid à l’intérieur de celui-ci.
Pour ce qui est de la commande drush, c’est encore plus simple. Un simple «cd /var/www/mon_site ; drush ma_commande» dans la ligne du CRON UNIX suffit.
Yoran - arNuméral
Yoran
1039
Merci Yoran pour ta réponse.
A priori je vais partir sur ta deuxième solution (hook_menu + hook_cron).
Donc si j’ai bien compris j’ai une url dédiée au lancement de mon script, donc une page joignable derrière cette url, et c’est cette url qui est déclenché par le cron ?
L’idée d’implémenter un hook_menu me plait, car me permettrait aussi d’exécuter manuellement le script et ce depuis le back office.
Je me lance.
Merci
ting
3
tu veux dire hook_menu+CRON via wget :)
Sinon oui, c’est cela. Tu va déclarer un menu du genre actions/mon_action et l’invoquer dans le CRON UNIX par :
<?phpwget http://mon_site/actions/mon_action
?>
Fait cependant très attention à la sécurité avec ce type d’approche car n’importe qui peut lancer cette URL s’il la connaît et il n’est pas possible de donner à WGET les droits d’accès admin par exemple. Du coup, tu es obligé de gérer une partie des droits à la main ce qui n’est pas forcement facile à blinder.
A toi de voir donc, moi je reste persuadé que la meilleur stratégie est une commande drush. Et avec une telle commande aussi, tu peux exécuter manuellement le script. Cela demande juste d’apprendre à faire de telles commande mais un exemple facile à modifier est présent dans l’archive du projet, à la racine, et c’est trééééés simple :)
Le seul avantage de la solution 2 est finalement de pouvoir facilement lancer ton script à distance. Mais tu peux aussi faire cela avec le terminal WEB de drush ou simplement (c’est ce que je fais à longueur de journée) par des appels SSH. Maintenant c’est vrai que drush est très naturel pour peu que tu sois Unixien, moins si tu es Windowsien (je ne présume là en rien de ce que tu «es» ou pas, c’est juste une remarque).
Yoran - arNuméral
Yoran
1039
J’ai donc opté pour la solution 2.
Il était nécessaire de pouvoir lancer le script simplement depuis le navigateur et de pouvoir l’exécuter quotidiennement via CRON.
Un grand merci pour ton aide.
ting
3