Pour les détails, c'est ici que cela se passe. A priori rien de bien extraordinaire même si 27 fichiers patchés pour deux anomalies, ça parait un peu gros 
Le dossier de travail d'un script PHP est l'endroit où il se trouve, physiquement. Donc, quelle que soit l'URL, on exécute le script se trouvant en /var/www/scritps/index.php, et que l'on cherche à y ouvrir le fichier qui lui se trouve dans /var/www/scritps/utilitaires/fichier.txt, cela nous donne :
Maintenant, si l'on effectue la même opération dans un script scripts/utilitaires/utilitaire.inc qui est inclus (directive include ou require) par index.php, le chemin sera... exactement le même. En effet, le dossier de travail de tous les fichiers inclus reste le même que celui du script principal. On peut s'en convaincre en utilisant la commande getcwd() qui retourne le dossier de travail :
La syntaxe précédente est tout sauf une bonne solution, surtout si l'on déplace ou renomme jour utilitaires. Il y a heureusement un moyen d'éviter ce problème en utilisant la macro PHP __FILE__ qui renvoiele nom de fichier complet (dossiers compris) du script qui la contient. Utilisé conjointement avec la fonction dirname, cette macro permet donc d'ouvrir plus naturellement notre fichier, devenant ainsi indépendant du nom et de l'emplacement final du dossier utilitaire.
Même si tout ce qui s'applique à un script principal s'applique aussi fichiers inclus, ces derniers ont de petites spécificités amusantes qu'il est intéressant de noter.
Par défaut, l'inclusion se fait en cherchant dans la liste de chemins contenus dans la variable include_path présente dans le fichier /etc/php.ini. Cette liste fonctionne un peu comme la variable PATH du système d'exploitation, PHP cherche de manière séquentielle les fichiers demandés dans cette liste de dossiers en commençant par le premier.
Généralement cette liste contient d'abord le dossier de travail représenté par un ., puis, selon les installations, une série de chemins vers des librairies (pear, librairies standard, etc...).
La présence du . en tête de liste implique un fonctionnement proche de ce que nous avons déjà vu plus haut avec fopen. Imaginons que le script a.php inclus b.inc qui inclus à son tour c.inc. Nous savons déjà que toute inclusion se trouvant dans c.inc sera recherchée dans les dossier de a.php et de c.inc. Mais, petite subtilité, il sera aussi cherché dans le dossier de b.inc.
La commande include (ou require) se comporte donc comme si à chaque appel, elle ajoutait dans include_path le dossier du script inclus. Comportement aussi pratique que dangereux car on ne sait plus bien où l'on en est au bout d'un temps, ni qui a la priorité sur qui. Sachant donc cela, le mieux reste à mon sens de coller à la logique générale, en oubliant se comportement particulier.
D'un point de vue général, le dossier de travail de drupal est celui où se trouve le fichier index.php. Ainsi tout ce qui a été dit plus haut fonctionne logiquement avec les scripts contenus dans Drupal, que ce soit pour le script principal, mais aussi pour les modules, thèmes et autre, qui ne sont que des include aux yeux de PHP.
La différence est que pour un module, le dossier final ne peut être prévu à l'avance. Il peut tout aussi bien se trouver dans drupal/modules que par exemple dans drupal/site/all/modules. Il est donc impossible de se baser sur un chemin en dur pour accéder aux ressources (include, fichiers textes, etc...). Et c'est encore plus vrai lorsque l'on doit référencer des éléments se trouvant dans un autre module.
Pour ces raisons, il est préconisé d'utiliser plutôt la fonction Drupal prévue à cet effet, drupal_get_path(...) qui permet de localiser précisément n'importe quel module :
Il est donc souhaitable d'utiliser cette fonction pour inclure dans la page finale les scripts et autres feuilles de style :
A noter que cette fonction ne renvoie pas un chemin absolu (comme _FILE) mais un chemin relative à la racine de Drupal (le répertorie de travail d'index.php), sans / ni au début, ni à la fin. Mais nous allons voir plus loin comment retrouver le dossier d'installation de Drupal dans le cas où nous aurions besoin d'un chemin complet.
Encore plus que celui du module, il est très utile de connaître le chemin vers le thème courant, utilisable par exemple dans les templates. Pour ce faire, nous avons deux options :
A partir de là, comme pour le module, il est possible d'accéder à toutes les ressources du thème (images, styles, etc..) avec des chemins relatifs.
Pour accéder au dossier files, seul emplacement avec le dossier temporaire où il est possible de créer des dossiers et d'écrire des données, vous pouvez faire appel à la fonction file_directory_path() :
Pour accéder cette fois au dossier temporaire, vous pouvez faire appel à la fonction file_directory_temp() :
Les pages générées par Drupal, prises cette fois du côté client WEB (firefox), contiennent sans aucun doute des références à des images et autres feuilles de styles par le biais d'URL. Comme nous l'avons vu plus haut, une partie de ces ressources (feuilles de style, scriptes) sont prisent en charge directement par Drupal avec la fonction drupal_add_css par exemple. En revanche c'est plus compliqué lorsqu'il s'agit, par exemple, de faire référence à une image contenue dans un module.
En effet, et c'est aussi vrai en simple PHP, l'URL qui est utilisée par le navigateur pour atteindre le script index.php contient un chemin qui peut être sans rapport avec le chemin physique du script. Cette différence tenant à la manière dont a été configuré l'ami Apache.
Par exemple, imaginons que noter site drupal est accessible par l'URL http://mon_site/drupal et que je veuille utiliser l'image photo.png contenue dans le dossier de mon_module, j'aurais tendance à écrire cela :
Alors comme cela, ça a l'air de marcher, et ça va marcher dans un seul cas, si l'URL de base de drupal est "simplement" http://mon_drupal/. En revanche cela va planter si l'url ressemble à quelque chose comme http://mon_site/drupal. Dans ce cas, la ressource va être recherchée au mauvais endroit, ou pire, dans un endroit qui n'existe pas.
La solution évidente semble être de passer en notation relative, en enlevant le premier slash. Et effectivement, cela va régler notre problème précédent mais il nous en reste un : les URL simplifiées.
En effet, si vous laissez Drupal configuré par défaut avec des URL du type http://mon_site/drupal/?q=node/12 vous n'aurez pas de problème. En revanche si vous activez la simplification d'URL (clean URL), cela devient http://mon_site/drupal/node/12. Et là les ennuis recommencent car en notation relative, vous allez demander au navigateur d'aller chercher votre image en /drupal/node/12 et non pas en /drupal.
Pour accéder de manière universelle à une ressource d'un module, il faut donc commencer par récupérer le /drupal/ quelque part. Et ce "quelque part" c'est le fichier settings.php, et plus précisément la variable globale $base_url qui contient l'URL de base de Drupal, soit dans notre exemple http://mon_site/drupal (sans / final). Le code de l'exemple précédent se corriger donc comme suit :
Cette solution marche très bien mais souffre d'un dernier inconvénient, celui d'inscrire dans le code HTML généré une URL absolue. Ce n'est pas très gênant, sauf si l'on a 1000 images impliquant une augmentation inutile de la taille du fichier.
Une bien meilleurs solution est donc d'utiliser cette fois la fonction base_path() qui ne renvoie que la partie correspondant au chemin de la variable $base_url (ex. drupal pour http://mon_site/drupal. Cela nous donne le code final : Ainsi nous pouvons réécrire notre exemple précédent :
Maintenant l'URL de notre image est relative et fonctionne dans tous les cas de figure. Bien évidement la même méthode peut être appliquée pour une ressource relative à un thème ou au dossier files.
Contrairement à ce que l'on imagine spontanément, un menu Drupal est avant tout une URL qui référence un traitement effectué par un module. A ce titre, /node/12 est un menu. Les menus "qui s'affichent sur le côté" ne sont du coup qu'un cas particulier d'un menu Drupal.
Très souvent dans un module, du code est généré pour faire référence à un menu drupal. Par exemple imaginons que nous désirions générer une page contenant le lien vers le menu node/12. La mauvaise méthode consisterait à écrire quelque chose comme cela :
Mauvaise pour les mêmes raisons que celles évoquées plus haut car si l'url contient un dossier en plus (http://mon_site/drupal), le menu devient alors http://mon_site/node/12 et cela ne marchera plus.
Drupal connaît "à l'avance" tous les menus possible car chaque module qui en donne, a le devoir de les faire enregistrer pour qu'ils soient utilisables. Il existe du coup une méthode magique qui permet de transformer un menu (ex. /node/12) en son équivalent URL, il s'agit de la fonction url(). En l'utilisant, notre code se transforme ainsi :
Cette méthode a plus d'un mérite. Tout d'abord elle va utiliser base_url() et gérer l'éventuelle absence de simplification d'url en mettant un ?q= si besoin est. De plus, si vous avec activé le module d'alias (aka path), elle va traduire node/12 en une-belle-url. Enfin elle renvoie une URL relative (donc plus courte) mais peut aussi créer une URL absolue en ajoutant des paramètres : url("node/12", null, null, true). Pour plus d'informations sur cette fonction incontournable, allez faire un tour ici.
Pour simplifier encore le travail, il existe une autre fonction qui fait appel à url() et qui permet de générer l'ensemble du lien. Avec son aide, notre code devient tout simplement :
Un autre moyen de référencer une ressource comme typiquement une image est de l'inclure dans une définition CSS. L'avantage de cette approche est que cette fois le chemin de la ressource n'est pas relatif à quoi que ce soit d'autre que la feuille de style elle-même. Ainsi si nous avons une feuille de style dans un dossier XXX, une image background.png dans le sous-dossier XXX/images, le référencement de cette image se fait tout simplement :
Voilà, c'est la fin de cette session de repérage dans l'arborescence d'une application WEB. Si vous voulez avoir un résumé de toutes ces fonctions en un coup d'oeil, vous pouvez créer un module simple, un menu avec un callback sur la fonction suivante :
Pour les détails, c'est ici que cela se passe. A priori rien de bien extraordinaire même si 27 fichiers patchés pour deux anomalies, ça parait un peu gros
Pour les détails, c'est ici que cela se passe. Et pour la mise à jour sans tout casser il y a ce tutoriel et bien évidement Drupal 6.5 ou Drupal 5.11.
Ah oui, et pour ceux qui veulent gagner du temps, voici le patch de la 6.4 à la 6.5. Ca a du me prendre 10 minutes avec ça de mettre à jour, alors pas de quoi s'en priver... En espérant qu'il n'y ait pas trop de regressions
Mais malgré cette richesse, il arrive parfois que l’on ne trouve pas LE module « qui va bien ». Alors pourquoi ne pas le fabriquer soi-même et ainsi découvrir à quel point Drupal s'adapte facilement à des besoins spécifiques.
]]>Mais malgré cette richesse, il arrive parfois que l’on ne trouve pas LE module « qui va bien ». Alors pourquoi ne pas le fabriquer soi-même et ainsi découvrir à quel point Drupal s'adapte facilement à des besoins spécifiques.
Les seuls pré-requis pour développer un module sont une bonne connaissance des concepts clés de Drupal (blocks, node, type de contenu, taxinomie, etc.), une relative maîtrise de PHP.
Armé de tout cela, nous allons commencer en douceur avec la création d'un module dont le seul but est de nous fournir un bloc avec du texte dedans, rien de plus. Ce module 'Liste des courses', sera ensuite étendu pour en faire un module complet de gestion de vos achats quotidien. Tant qu'à prendre un exemple, autant qu'il serve à quelque chose (quoi ? vous n'avez pas tous un intranet domestique sous Drupal ??? ). Et tout cela pour Drupal 6.x.
Avant de poursuivre, il est important de comprendre ce qu'est réellement un module. Un module Drupal est un bout de code PHP que l'on peut activer ou désactiver, et qui implémente des "hooks".
Un hook (en français, "Crochet") est un prototype de fonction dédié à une tâche spécifique, comme par obtenir la liste des blocs disponibles et le contenu de chacun d'entre eux.
Chaque module peut ainsi implémenter ce hook sous la forme d'une fonction ayant des paramètres calqués sur ceux du prototype. Dans le cas d'un bloc, le prototype se nomme hook_view:
prototype du hook 'hook_view'
Ainsi un module désirant implémenter ce hook, devra comporter le code suivant :
Lorsque Drupal aura besoin d'obtenir la liste des blocs, il cherchera dans la liste de toutes les fonctions PHP disponibles, c'est-à-dire les fonctions contenues dans tous les modules activés, celles dont le nom commence par le nom d'un module et se termine par _block, le nom du hook.
La manière dont Drupal utilise un hook est assez simple. Pour rester sur notre exemple, lorsqu'il a besoin d'obtenir la liste des blocs, il va appeler tout les fonctions _block qu'il trouve, les unes après les autres, en leur passant en premier paramètre la chaîne list. Et réponse, chacune va donner un tableau contenant les noms et descriptions des blocs qu'elles prennent en charge.
Ensuite lorsque Drupal va devoir afficher un bloc en particulier, il effectue la même opération mais cette fois en passant en paramètre view suivi du nom du bloc.
Maintenant au delà du mode d'exécution des hooks de même type, chacun est spécifique tant par les paramètres qu'il reçoit que par les valeurs que Drupal s'attend à recevoir. Vous pouvez obtenir leur description dans la documentation de l'API Drupal.
Un module est donc un fournisseur d'implémentation de hooks. En conséquence, la majeure partie de son code va s'insérer dans les traitements de Drupal et étendre son comportement. Maintenant de manière plus prosaïque, un module est simplement un dossier qui contient au minimum deux fichiers.
Ce dossier doit porter le nom du module et doit être placé dans l'arborescence de Drupal, à un endroit qui soit approprié pour que ce dernier puisse le voir. Techniquement il est possible de les mettre dans modules/ mais vous seriez vite embêtés lors d'un changement de version. Il est donc préconisé de mettre cela dans un dossier sites/all/modules/mes_modules que vous créerez si nécessaire. Ainsi lorsque vous changez de version, il suffit de déplacer le dossier sites à sa place dans la nouvelle arborescence.
Dans ce dossier mes_modules, vous allez donc créer le sous-dossier du module lui-même, dans notre cas courses. A l'intérieur de celui-ci, vous devez avoir au minimum deux fichiers, portant le même nom de base que le dossier parent : courses.info et courses.module. Ce qui nous donne l'arborescence suivante :
Le fichier statistiques.info est un simple fichier texte contenant des informations sur le module comme son nom, sa description, la version de Drupal avec lequel il est compatible, etc. Ce qui nous donne pour notre exemple, le contenu suivant :
package indique dans quelle catégorie le module doit être affiché. name, description sont des informations textuelles qui seront affiché dans le panneau d'administration des modules. name reprend le nom du module (qui est aussi le nom du dossier). version indique quant à lui la version du module. C'est d'ailleurs plus une norme qu'autre chose qui se lit "Module version 0.1 pour Drupal 6.x". Enfin core prévient Drupal que le module est seulement compatible avec sa version 6.x. Tout autre version de Drupal empêchera le module de s'activer.
Si nous avions eu besoin de définir une dépendance avec un autre module, nous aurions ajouté une clause de la forme dependencies[] = autre_module. Enfin, si vous désirez ajouter des commentaires, il suffit d'utiliser le symbole ; suivi du texte du commentaire.
Le second fichier est le code PHP du module. C'est lui qui va héberger les hooks que nous souhaitons implémenter. Pour l'instant, nous allons faire simple et n'en mettre aucun. Notre fichier va donc contenir une simple balise de démarrage de code PHP :
Voilà, nous avons maintenant un module aussi simple qu'inutile, que Drupal est cependant capable de voir et d'activer. Pour s'en convaincre, il suffit d'aller faire un tour en http://mon_site_drupal/?q=/admin/build/modules pour le voir apparaître dans la liste. Vous constatez que les informations affichées sont les champs name et description de notre fichier courses.info.
A ce stade nous pourrions donc activer notre module, mais ne le faites pas tout de suite, nous avons encore quelque chose à rajouter.
Il est maintenant temps d'implémenter notre premier hook. Comme nous l'avons vu plus haut, celui qui est responsable de la génération de bloc est hook_block. Il nous faut donc ajouter son implémentation à la suite, dans notre fichier statistiques.modules:
Le paramètre important de ce hook est $op. Lorsque Drupal a besoin de la liste des blocs disponible, il appelle cette fonction avec $op=='list'. Drupal s'attend alors à ce que la fonction renvoie un tableau associant un id (ici courses) à une définition de bloc. Cette définition est elle aussi un tableau associant une propriété du bloc à sa valeur. Cette organisation des données est un grand classique dans Drupal.
Ici nous renvoyons à Drupal un seul bloc ayant pour description (propriété info) affichage des statistiques. Notez l'utilisation de la fonction t(...) qui permet de prévoir une prise en charge ultérieure de la traduction du module. Pensez à utiliser systématiquement cette fonction pour tous les textes.
Vous pouvez dés maintenant voir le hook en action en allant sur l'URL http://mon_site_drupal?q=admin/build/block. Vous devriez alors le voir apparaître dans la liste des blocs désactivés.
Sélectionnez maintenant dans la liste une position pour votre bloc et sauvegardez l'ensemble. Il devrait apparaître à l'endroit désiré.
Passons maintenant à la possibilité d'ajoute un formulaire de paramétrage pour notre bloc. Cela se passe toujours dans hook_bloc mais nous nous adressons cette fois aux opérations $op==configure et $op==save. La première fabrique un mini formulaire Drupal. La seconde sauvegarde le résultat du formulaire modifié par l'utilisateur.
Le formulaire est construit dans la variable $form dont la structure de stockage est la même que pour $blocks. C'est à dire un double tableau associatif, contenant la liste par id des champs. Puis par champ, la liste des propriétés et leurs valeurs.
La propriété #type détermine le type du champ (zone de texte,liste déroulante, etc). Ici nous choisissions un champ texte (textfield). La liste de complète des types et de leurs propriétés associées est disponible dans la documentation de Drupal.
Mais la propriété vraiment intéressante est #default_value. Elle définit la valeur que dois prendre le champ au moment de l'affichage du formulaire. Cette valeur est extraite des propriétés générales de Drupal par la fonction variable_get(...), par l'intermédiaire de la fonction courses_nombre_item_max(). En effet, Drupal met à disposition des modules un système de variables persistantes très simple à mettre en oeuvre. Passer par une fonction intermédiaire nous permet seulement de définir la valeur par défaut ((ici 5) de cette variable à un seul endroit et d'utiliser cette fonction partout où nous auront besoin de ce paramétrage.
La dernière propriété #title définit le titre du champ. Là aussi nous utilisons la fonction t(...) en prévision d'éventuelles traductions à venir.
Notre micro formulaire est maintenant prêt à être utilisé par Drupal. Vous pouvez le tester en retournant dans l'administration des blocs, en allant à la ligne que vous avez activée plus haut et en cliquant sur le lien configurer.
Lorsque vous aurez paramétré votre bloc, le fait de clicker sur le bouton Enregistrer le bloc provoquer un nouvel appel de notre hook, mais cette fois avec le paramètre save renvoyant les résultats du formulaire définit à l'étape précédente. Ces résultats sont contenus dans le tableau associatif $edit et notre seule tâche est d'utiliser la fonction Drupal permettant de stocker une variable persistante, variable_set(...);, en lui passant la valeur du champ courses_nombre_item_max.
La dernière étape est la génération du code HTML du bloc. C'est le rôle de l'opération $op==view qui utilise le paramètre du hook $delta.
hook_block permettant de créer autant de blocs que désiré, $delta contient l'ID du bloc à créer. Ici nous n'en avons qu'un mais autant prévoir l'avenir et effectuer tout de même le test. Ensuite, nous définissons une fois de plus un tableau associatif contenant deux propriétés, le titre du node (subject) et le contenu HTML du node (content).
Maintenant que notre bloc est prêt, passons à l'affichage de son contenu. Pour cela nous allons remplacer la ligne content' => 'Un bloc vide'); par 'content' => statistiques_contenu()); et ajouter la fonction de rendu HTML de notre bloc. Bien évidemment, vu que nous n'avons pour l'instant pas de base de données contenant la liste réelle de nos courses, nous allons mettre dans ce bloc des items poétiques :
Voilà, nous avons terminé notre premier module totalement fonctionnel en espérant que vous avoir montré à quel point, une fois quelques notions de base assimilées Drupal est facile à adapter à des besoins même très particuliers.
]]>Mise à part cela, des statistiques d'avancement ont été ajoutées, quelques corrections aussi, et c'est un peu plus rapide que la dernière version.
Sinon, le projet est passé sur drupal.org, donc s'il y a des anomalies, c'est ici que ça se passe.
]]>
Dans son fonctionnement standard, le module utilise le CRON de Drupal. A chaque itération le moteur va pouvoir analyser le contenu des nodes, des commentaires, ou les deux. Pour chaque catégorie de contenu, il est possible de spécifier un nombre maximum à analyser. Il est aussi possible de désactiver l'analyse d'un type de contenu (par exemple les commentaires).
Sur chaque contenu sont appliqué l'ensemble des formats d'entrées qui lui sont associés de sorte à avoir un résultat équivalent à ce qui est affiché. Ensuite sont recherché l'ensemble des chaînes correspondant à des URL (balise HREF, IMG, etc.) et effectue une connexion sur le site associé pour en vérifier le statut. Il est possible dans les réglages d'ajouter des exceptions.
De manière optionnelle, le moteur va aussi rechercher des motifs correspondant à des adresses courriel en clair (qu'elles soient ou pas dans un href). Là aussi il est possible d'ajouter des exceptions.
Le module fournit ensuite un rapport paginé, classé par ID de contenu (commentaire ou node) avec un lien vers l'adresse fautive, un autre vers l'édition du contenu fautif, et un statut indiquant l'erreur rencontré (404 Not Found, 403 Forbidden, Timeout, etc.)
Pour chaque ligne il est possible de relancer la vérification qui du coup portera sur ce seul contenu, faisant disparaître les erreurs du rapport s'il a été corrigé.
Voilà, j'espère que cela servira à d'autres et bonne chasse au liens cassés.
]]>