Le Pas à pas

Pour traquer les cafards, nous allons tout d'abord utiliser Eclipse et l'excellent plugin PDT. Pour l'instant, pour le développement PHP, j'utilise conjointement PDT 1.x et Eclipse 3.3 (Europa) en attendant que PDT 2.0 se stabilise et puisse fonctionner correctement avec Eclipse 3.4 (Ganymede).

Une fois le plugin installé dans eclipse avec l'url de mise à jour http://download.eclipse.org/tools/pdt/updates/, il reste à ajouter Xdebug à la votre plateforme de test. Je pars du principe qu'Apache et PHP sont déjà installé et que le serveur est en écoute sur localhost.

Il y a de très fortes chances que xdebug soit déjà inclus dans votre distribution. Sous Mandriva, cela passe donc simplement par un urpmi php-xdebug. Sur les debian-like j'imagine qu'un coup d'apt-get ne doit pas tomber très loin.

Une fois le paquet en place, reste à configurer PHP pour qu'il utilise cette nouvelle extension. Toujours sous Mandriva, cela se passe dans le fichier /etc/php.d/A29_xdebug.ini. Là nous allons rechercher une série de variables suivantes à modifier :

Ici nous avons activé le debugger à distance,indiqué qu'il devait se connecter sur localhost9000, au port 9000 (nous verons pourquoi plus loin), en utilisant le protocole de communication dbfp (et non plus l'ancien dbg).

Ceci fait, un coup de redémarrage d'apache et nous pouvons retourner sous Eclipse.

Là encore, quelques réglages sont nécessaires. Déjà il nous faut configurer un navigateur par défaut. Pour cela, faite un tour dans Windows/Préférences (me demandé pas pourquoi ils ont clocké ça là dedans...), General/Web Browser. Là vous ajouterez votre navigateur préféré en prendrez soin de le cocher une fois l'opération réalisée pour le rendre actif par défaut.

Ne partez pas tout de suite, et allez dans la section PHP/Debug. Là vous pouvez sélectionner xdebug et clicker sur Configure, histoire de vérifier que le host est bien localhost et le port 9000, comme nous l'avions configuré pour PHP.

Voilà, vous pouvez clicker sur OK pour valider ce paramétrage.

Maintenant, il ne nous reste plus qu'à lancer l'application en mode déverminage par Run/Debug As/PHP Web Page. Comme c'est un nouveau lancement, on vous demande une URL qui est généralement fausse. Remplacez cela par celle de la page à tester. Une fois validée, le navigateur s'ouvre et l'exécution s'arrête brutalement sur le première ligne du premier script PHP. Après c'est du classique, vous avez accès au pas à pas (F6), aux points d'arrêt, à la visualisation des variables par survol, l'ajout d'expressions watch, etc...

Analyse de performances

L'intérêt de Xdebug ne s'arrête pas au debuggage, loin de là. C'est aussi un formidable outil d'analyse de performance (profiling). Pour activer ce mode, il faut retourner dans le fichier de configuration de Xdebug pour modifier comme suit :

Attention, cette fois il est très claire qu'activer cela nuit gravement aux performances. Activez et désactivez donc xdebug.profiler_enable selon vos besoins.

Une fois le serveur Apache redémarré, il ne vous reste plus qu'à aller faire un tour sur la page qui explose les compteurs de temps. Quant vous avez terminé, retournez voir dans le dossier /tmp où devrait se trouver un php_profile.txt, c'est lui qui contient tous les temps d'exécution enregistrés par Xdebug.

Pour visualiser le résultat, malheureusement il n'existe pas (à ma connaissance) d'application GTK. Mais il y a néanmoins le très bon kcachegrind qui permet une exploration précise et rapide des temps d'exécutions.

Conclusion

Xdebug fait à mon sens parti de la trousse à outil de base lorsque l'on porte sa casquette de développeur (ou pompier PHP. Il n'empêche pas de coller nos error_log de base mais aide énormément lorsque l'application patine ou qu'un algo part en vrille.

Ce serait sans compter sur la commande chroot qui permet dans certaines conditions d'obtenir un environnement de test ou d'intégration identique à celui en production, sans machine physique supplémentaire et sans que la machine principale soit ralentie ou compromise.

Qu'est-ce qu'un chroot?

Comme vous le savez sûrement déjà, le système fichier d'un *NIX est construit autour d'une racine (le /) sur laquelle les partitions sont ensuite "montées" formant ainsi l'espace de fichier accessible. Ce que l'on sait moins c'est que cette racine est un paramètre du processus. Tout processus lancé peut avoir pour racine un chemin arbitraire issu de celle de son processus parent. Si ce paramètre n'est pas définit, ce qui est généralement le cas, c'est '/' qui est utilisé par défaut, en quelque sorte la racine de la racine du parent. La commande chroot permet de lancer une commande et dans la foulée de définir ce paramètre pour le processus engendré.

La commande chroot peut donc avoir deux paramètres principaux : un chemin dans l'arborescence et une commande. Ainsi, si en tant qu'utilisateur root nous lançons chroot /lapp /bin/bash, voilà ce qui se passe :

1. La commande chroot engendre un processus qui a pour racine la même que celle de son processus parent, généralement le / (mais rien n'empêche de faire des poupées russes...).
2. En interne, chroot appel de la fonction kernel chroot("/lapp"). Le kernel va donc modifier la valeur de la racine pour ce processus et lui associer la valeur /lapp.
3. Le processus de chroot, exécute la commande passée en 2nd paramètre, /bin/bash. Comme la racine de chroot a été changée, c'est en quelque sorte bien le /bin/bash à partir de la nouvelle racine /lapp qui va être exécuté.
4. Cette exécution débouche sur la création d'un processus fils de celui du chroot qui hérite donc de cette nouvelle racine.
5. Tout ce que /bin/bash lancera par la suite héritera de cette nouvelle racine jusqu'à ce que l'on tape exit qui mettra fin au processus /bin/bash, et par domino à celui du chroot qui a permis son lancement.

Le premier constat que nous pouvons tire de cela est qu'il faut que notre dossier /lapp contienne un bin/bash, mais aussi toutes les librairies dont a besoin bash pour fonctionner, ainsi que tous les dossiers systèmes qui lui sont nécessaire et qu'il s'attend à trouver comme sous une "vraie" racine. Ainsi la seule problématique posée sera le peuplement de notre nouvelle racine.

Le second constat est qu'un chroot n'est pas une virtualisation. Une virtualisation définit des conteneurs bien hermétiques avec leur mémoire propre, leur espace disque propre, leurs périphériques propres, etc. Le chroot ne fait rien de tout cela. La mémoire, le CPU, les périphériques (réseau, disque, écran, etc) sont partagées par l'environnement racine et chrooté. C'est d'ailleurs pour cela qu'un chroot est aussi rapide que si tout était lancé sur la racine principale.

Chroot ne fait donc que "faire croire" à un processus qu'il travaille sous la "vraie racine" alors qu'il n'est que dans un sous-dossier. Ainsi la seule garantie que fournit le chroot est l'étanchéité des fichiers dans le sens enfant-parent. C'est pour cet aspect que le chroot est d'ailleurs généralement utilisé, pour "mettre en prison" des applications critiques (serveur web, serveur mail, etc.) de sorte à ce que si une vulnérabilité permet à un cracker de casser le serveur, il ne puisse atteindre les fichiers se trouvant hors du chroot et ainsi limiter les dégâts. A noter que ce billet ne traite pas de cette utilisation critique du chroot et que d'un point de vue général il existe nombre d'exploits permettant de s'échapper de cette prison.

Malgré ses limitations, le chroot est juste parfait pour une utilisation : la création d'un environnement de test et/ou d'intégration pour des applications WEB. Il permet en effet très facilement de créer une configuration LA(P|M)P (Linux-Apache-Postgres/MySQL-PHP), facile à maintenir, facile à recréer, testable de la machine principale sans modification particulière comme si tout était installé "localement".

Mise en oeuvre

Notre but est donc ici de créer un environnement chrooté comprenant un Linux de base, Apache, Postgresql et PHP. La première étape est donc de créer notre future racine. Je le fait en /lapp mais cela pourrait être virtuellement n'importe où, y compris sur le dossier d'une clef mémoire ou sur un espace volatile type tmpfs.

Maintenant vient le moment de peupler notre racine. Là, il y a trois approches possibles.

Nous avons l'approche dite "bourrine" consistant à dupliquer sauvagement son environnement principal :

L'inconvénient est que c'est souvent très volumineux et peu adapté à un environnement de test contrôlé dans la mesure où des tas de choses inutiles sont injectées dans la nouvelle racine.

Ensuite il y a l'approche "minimaliste" qui cherche à ne copier que ce qui est nécessaire. Cela peut se faire à la main avec la commande ldd ou beaucoup plus simplement, comme me l'a indiqué Guyou, avec les outils makejail ou chrootbin. Mais cette technique est plus adaptée au lancement d'un serveur dans une prison chroot qu'à notre besoin.

Enfin nous avons l'approche "raisonnable" consistant à utiliser les outils fournis par les debian's et autres mandriva's qui permettant d'installer tout simplement sur une racine arbitraire une distribution complète. C'est clairement dans notre cas cette approche qui s'impose.

Sous mandriva (et distributions dérivées), l'installation d'un linux de base sur une racine se fait simplement par la commande suivante :

Simple et diablement efficace. Comme vous l'aurez noté, ce sont trois paquets qui sont ici installés: le linux de base, la langue française et le système de gestion de paquets. Ce dernier point nous offrira beaucoup de souplesse car au sein même du chroot il sera du coup possible d'installer, désinstaller ou même mettre à jour la distribution.

Les distributions basées sur debian disposent elle aussi d'une méthode très efficace pour créer une racine minimale en utilisant cette fois la commande debootsrap.

Vous pouvez remplacer sid par toute distribution debian disponible (etch, sarge, etc..). Pour le reste cela fonctionne comme la méthode précédente a la différence que la gestion de paquet n'est pas optionnelle et vous aurez donc automatiquement accès à apt-get dans le chroot.

Notre racine étant maintenant peuplée et les utilitaires que nous avons utilisé ont normalement pris soin de créer à la "racine" les dossier vitaux tmp, var, dev, sys et proc. Si ce n'est pas le cas, faites le vous-même.

Maintenant comme vous le savez, certains dossiers de Linux ne sont pas de "vrais" dossier mais une vue sur des variables du système. C'est le cas de /proc, /sys et /dev. Si nous lancions maintenant notre nouvelle racine, ces dossiers seraient donc vides provoquant des erreurs sur certaines fonctions. Il nous faut donc avant monter ces dossiers. Pour ce faire, nous allons simplement les "relier" (mount --bind) aux mêmes dossiers de la vraie racine.

Concernant le réseau dans un chroot, la configuration sera la même que celle de l'environnement parent. Tout fonctionnera donc sans avoir à faire quoi que ce soit. En revanche il est important de vérifier que la résolution de noms se fait correctement. Pour cela nous allons simplement recopier le fichier /etc/resolv :

Maintenant tout est en place, c'est le moment du lancement.

Voilà, une fois ceci exécuté, nous sommes "prisonnier" de la nouvelle racine et toutes les commandes qui suivent sont contrainte dans cet espace. Pour en sortir il suffit de faire un "exit". Comme vous le voyez tout fonctionne, vous pouvez utiliser le réseau, installer des paquets, etc. C'est ce que nous allons faire pour mettre en place notre environnement de test :

Ceci fait, vous pouvez constater que votre système fonctionne en lançant les services :

Maintenant, en allant, sur votre environnement principal aidé d'un navigateur web sur l'adresse http://localhost, vous devriez avoir accès à la page de test du serveur Apache. Pour le reste, à vous de jouer...

Automatisation

Comme vous l'aurez constaté, le chroot n'effectue pas, et heureusement, un démarrage réel du linux installé à la nouvelle racine. Il se contente d'exécuter /bin/bash ce qui vous oblige de votre côté à lancer les services à la main.

Pour rendre cela beaucoup plus simple à utiliser sur une base quotidienne, le plus propre reste de créer un service dédié au lancement de notre racine qui va créer le montages et lancer apache, postgres, etc... Son arrêt ferra l'inverse :

Ensuite dans notre racine il faut rajouter, et rendre exécutable, un fichier /init.sh contenant le démarrage/arrêt des services httpd et postgresql, et qui prendra en paramètre start ou stop :

Après, vous pouvez rendre le lancement de ce service automatique (avec chkconfig ou l'outil dédié à cela pour votre distribution), ou faire cela à la main :

Personnellement j'ai mis ce service en démarrage manuel et ajouté un profile dans gnome-terminal qui me lance directement la commande chroot /lapp /bin/sh.

Conclusion

La commande chroot ne manque donc pas d'intérêt en restant très simple à mettre en oeuvre si on en saisi bien les fondamentaux. C'est une bonne alternative à la "lourdeur" de la virtualisation et permet de créer à une vitesse record des environnements de développement rapides, efficaces et non-polluant pour le reste du système.

Analyse de la requête Google

Dans le temps, il existait une extension pour faire ce qui suit, Open Search Fox, mais elle n'a pas été portée avec FireFox 3.0 et tout semble indiquer qu'elle ne le sera pas. Alors même s'il existe une autre extension du même genre ou si quelqu'un se décide à porter celle-là, autant savoir faire sans. Ceci d'autant plus que c'est assez simple.

Histoire de prendre un exemple, disons que je veuille utilisez les fonctions étendues de Google pour rechercher un projet Drupal particulier. Cela corresponds à taper dans Google site:drupal.org inurl:project webdav.

Lorsque vous avez lancé cette requête, vous obtenez avec la page de résultat, dans la barre d'adresse, quelque chose commençant par http://www.google.fr/search?q=site%3Adrupal.org+inurl%3Aproject+webdav. Oubliez le reste, cela n'a pas d'importance. Nous constatons donc que l'URL de la recherche est http://www.google.fr/search, qu'il y a un paramètre nommé q et que sa valeur est site%3Adrupal.org+inurl%3Aproject+webdav. Dans cette valeur, webdav sera par la suite à remplacer par le nom du projet que l'on va effectivement rechercher. Le début sera toujours le même.

Ajout de la requête

Pour mettre cette requête dans Firfox, il faut commencer par trouver le dossier de votre profile, généralement ~/.mozilla/firefox/XXXXX.default. Là se trouve le répertoire qui nous intéresse, searchplugins. Vous allez y créer un fichier drupal-projects.xml :

Avant de redémarrer FireFox, quelques explications s'imposent. Déjà ShortName représente comme on se l'imagine le nom qui apparaîtra dans la liste déroulante de FireFox. InputEncoding permet de passer à Google une chaînes avec les accents correctement encodés. Et enfin Image pointe sur l'URL de l'icône qui va illustrer notre requête.

La partie intéressante arrive avec Url. Il s'agit d'invoquer la méthode GET sur une URL donnée par l'attribut Template. Cela implique qu'il est parfaitement possible d'utiliser la méthode POST qui peut être nécessaire pour certain sites qui utilisent des formulaires de recherche complexes.

Ici l'URL de base de la recherche est donc http://www.google.fr/search. Maintenant, il reste encore à envoyer à Google le paramètre, q, c'est le rôle de la balise Param.

Comme nous l'avons vu plus haut, la valeur de q est composée de site%3Adrupal.org+inurl%3Aproject+, suivi du nom du projet à chercher. Ce nom est ici {searchTerms} qui indique à FireFox de placer là les mots que l'utilisateur a tapé avant de lancer la recherche. FireFox s'assure de la bonne conversion de la phrase, en convertissant, entre autre, les espaces par des +.

Et voilà, c'est tout. Redémarrez FireFox et la nouvelle recherche devrait apparaître prête à être utilisée.

Image embarquée

Ici, nous donnons l'URL de l'icône dans la balise Image, mais il est aussi possible de directement intégrer cette image au fichier XML. Pour cela il faut encoder le fichier d'origine en un fragment de texte encodé base64. Pas évident. Heureusement, il existe de petits outils en ligne comme ici, à qui l'on donne l'URL et qui nous renvoient un bloc de texte à coller directement dans le contenu de la balise Image. Dans notre cas, nous utiliserons http://drupal.org/misc/favicon.ico.

Conclusion

Cette syntaxe n'est pas une exclusivité de FireFox. En réalité ce dernier ne fait qu'exploiter le format OpenSearch qui a été conçu par A9, une filiale d'Amazon. Ce format permet non seulement d'ajouter des automates de recherche à un navigateur comme nous l'avons fait ici, mais aussi, et surtout, donne à un site la possibilité d'indiquer à un navigateur le moteur de recherche qui lui est le plus adapté. Comme pour les flux Atom ou RSS, cela se fait très simplement en incluant dans chaque page du site une balise link, comme par exemple :

Du coup, lorsque le navigateur affiche cette page, il découvre cette balise et peut vous proposer d'ajouter ce nouveau moteur de recherche. Vous pouvez tester cela avec ce site. Allez dans la zone de recherche, déroulez la liste et vous devriez voir apparaître Ajouter "Artisan Numérique".

Sources

Les sources du module d'exemple courses sont disponibles ici.

Mise à jour du schéma

Comme depuis un moment déjà nous allons continuer à torpiller notre liste de courses à qui nous avions récemment ajouté les nouveaux schémas de Drupal 6.

Pour les besoins de l'expérience, nous allons ajouter deux nouveaux champs à notre table node_produit : categorie_produit et type_produit. Le but est simple, lors de l'ajout ou de l'édition d'un produit, nous aurons une liste permettant de choisir la catégorie (féculents, jus de fruits, légumes, etc.). Et lorsque l'utilisateur sélectionnera un élément de cette liste, cela déclenchera la mise à jour d'une seconde liste de types de produit (pâtes, choux, jus d'orange, etc.). Un peu neu-neu, je sais, mais au moins on peut se concentrer sur la technique.

Pour commencer nous allons rapidement modifier le schéma de notre module (courses.install) en ajoutant nos deux champs :

Ensuite, il nous faut implémenter un nouveau hook_update pour permettre la mise à jour des anciens schémas :

Ceci fait, lancez la procédure de mise à jour de Drupal (update.php) au terme de laquelle, note table devrait être modifiée.

Source de données

Pour une véritable application, nos données catégories et types seraient proprement stockées en base de donnée. Ici, nous allons faire simple avec deux fonctions en dur :

Liste maître-esclave

A l'ancienne mode, cela aurait consisté à utiliser le très vilain attribut de formulaire DANGEROUS_SKIP_CHECK et ajouter un bouton qui provoque une validation intermédiaire. Aujourd'hui trois arguments s'y opposent. Tout d'abord DANGEROUS_SKIP_CHECK a été supprimé. Ensuite les formulaires sont tous mis en cache et donc difficile à modifier dynamiquement. C'est ceci dit faisable en utilisant l'attribut de champ #process et de formulaire #REBUILD mais le fait de ne pas pouvoir by-passer les contrôles implique qu'à chaque mise à jour de la liste s'affiche des erreurs de validation, c'est moche. Enfin dernier argument, c'est pas AJAX donc c'est pas bien, on m'a dit...

Le framework AHAH qui était un module pour Drupal 5, fait aujourd'hui parti du coeur de Drupal 6. Cette librairie utilise jQuery pour ajouter à Drupal cette giclée d'AJAX qui lui manquait temps. La différence entre AJAX et AHAH (Asynchronous HTML over HTTP, me demandez pas pourquoi) est que le résultat de la réponse est du XHTML qui est directement collée dans le document en cours avec de petits effets genre glissement, fondus, etc...

Il faut donc voir AHAH comme un sous-ensemble fonctionnel d'AJAX et cela va nous suffire car c'est exactement ce dont nous avons besoin.

L'intégration dans un formulaire d'AHAH est relativement directe. Pour nous deux listes, cela donne ceci (à placer à la tête de la fonction courses_form :

Simple mais nécessitant un peu d'explication. Le début de l'élément de formulaire categorie_produit ne change pas par rapport à ce que nous connaissions. Elle est alimentée par la fonction courses_categories() que nous avons défini plus haut et utilise $node->categorie_produit comme valeur par défaut.

Là où cela change, c'est justement avec l'attribut #ahah qui définit un comportement AJAX, pardon AHAH, que la liste doit adopter. Le bloc AHAH n'ayant pas d'attribut event, va aller se connecter à l'événement par défaut, à savoir la sélection d'un élément de la liste. Nous aurions pu rajouter un 'event'=>'mousedown' mais cela n'aurait pas grand intérêt. wrapper indique l'ID d'un DIV qui va recevoir les données, method dit que cette réception doit donner lieu à un remplacement de ce que contenait le DIV (cela pourrait être before ou after), effect, c'est pour faire joli, mettez none si vous n'aimez pas, et enfin path est l'URL vers laquelle le module AHAH doit émettre une requête pour recevoir ce fameux contenu à coller dans le DIV.

Ce fameux DIV est défini par l'élément de formulaire suivant avec comme ID, celui qui a été donné plus haut, et comme contenu notre fameux champ dynamique. Et comme il est dynamique, sa construction est placée dans une fonction que nous allons maintenant définir :

Rien de compliqué là dedans, il s'agit juste de la récupération de la bonne liste de types en fonction de la catégorie et éventuellement de la définition d'une position par défaut si le paramètre $type est renseigné (cas de l'édition d'un produit).

Voilà, le décor est en place, passons à la partie rock'n'roll, la réponse à la requête AHAH.

Requête AHAH

Comme nous l'avons vu, le module AHAH est censé lorsque l'utilisateur sélectionne un élément de la liste categories, émettre une requête vers courses/js/types de sorte à recevoir le nouvel élément de formulaire qui va aller remplacer l'ancien. Pour que Drupal sache répondre à cette requête, il faut donc déjà rajouter un nouveau menu (à placer avant le return $items :

Rien de nouveau ici, cela reprend la technique plus laborieuse que j'avais utilisée pour faire causer jQuery avec Drupal. Il nous reste donc à ajouter notre callback :

Alors oui, j'en conviens, c'est un peu "sportif". L'idée est que AHAH ne fait pas un GET mais un POST du formulaire dans son état courant. Du coup, nous avons toutes les valeurs que l'utilisateur a déjà saisies, dont la catégorie, dans la variable $_POST. Cela nous permet déjà de construire notre élément dynamique.

Une valeur un peu étonnante envoyée par POST est form_build_id. Il s'agit de l'ID unique de l'instance du formulaire pour cet utilisateur. Et nous allons utiliser cet ID pour aller faucher dans le cache le formulaire complet tel que Drupal l'a sauvegardé avant de l'envoyer. Ensuite nous allons remplacer dans ce formulaire l'ancien élément type_produit par le nouveau et sauver le tout dans le cache. Alors pourquoi se compliquer la vie ainsi ? Simplement pour tromper Drupal et lui faire croire que le formulaire que nous sommes en train de modifier dans son dos est le même que celui qu'il a originellement envoyé à l'utilisateur.

Pour terminer, nous allons utiliser la fonction form_builder qui va régénérer le formulaire dans le même état que si Drupal était sur le point de l'envoyer. La seule différence est que nous allons extraire notre élément 'type_produit' de ce formulaire regénéré pour le passer à la fonction drupal_render qui va le transformer en code XHTML.

Dernière étape, l'utilisation de drupal_to_js qui va transformer ce code XHTML en un fragment au format JSON que le module AHAH du client est capable de comprendre. Une fois cette dernière transformation faite, le tout est simplement envoyé au client.

Notez la fonction exit() qui arrête le traitement ici, interdisant à Drupal tout autre opération.

Conclusion

Voilà, c'est tout et ça marche très bien. Ne vous laissez pas trop effrayer par l'apparente complexité de l'approche car je l'ai développée au maximum. Il est possible de créer une ou deux fonctions génériques qui permettraient de faire la même chose en quelques lignes. Si cela continue dans cette voie, on va finir par pouvoir faire des choses aussi basiques que celles-ci avec la même simplicité que les Delphi & co d'il y a 10 ans... Enfin, je rêve un peu, avec les client Riches, il a fort à parier que tout cet acquis soit à nouveau remis en jeu...