Une des grandes forces de Drupal réside en son architecture à base de modules. Que ce soit pour la gestion des blogs ou celle d’un forum, chaque fonction fondamentale est en réalité un simple module interagissant avec le cœur de Drupal. Et si les modules fournis en standard ne suffisent pas, des centaines d’autres sont disponibles couvrant à peu prés tous les usages.

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.

Debugger une application PHP se résume souvent à coller des error_log un peu partout dans le code. Mais lorsque le dit code commence à passer une taille critique, cette option devient vite ingérable. C'est là qu'intervient Xdebug, le concurrent libre du debugger de Zend.

Lorsque l'on a besoin de créer un environnement de test il est nécessaire que sa composition soit strictement contrôlé (paramétrages, applications et services disponibles et lancées, etc). Il n'est du coup généralement pas conseillé d'utiliser sa machine de travail, sauf si elle ne sert qu'à cela, sous peine d'en détériorer le fonctionnement en cas de test malheureux ou de modifier sans le vouloir le comportement de ce que l'on cherche à tester. Nous sommes alors contraints d'avoir soit une machine virtuelle dédiée aux tests, soit une machine physique supplémentaire.

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.

La zone de recherche de FireFox est bien pratique, difficile de remettre cela en cause. Son seul problème est qu'il n'y a étrangement aucun moyen en standard pour ajouter des requêtes un peu exotiques. Voici donc comment faire.

Les formulaires dynamiques sont vieux comme le client-serveur. Cela peut correspondre par exemple à une liste principale dont le choix d'un élément déclenche la population d'une liste secondaire. Rien de bien sorcier donc, mais comme pour pas mal d'autres choses, ce qui était relativement simple à coder avec un

RAD
comme Delphi, ou même Visual Basic, est devenu un véritable enfer avec la mode des applications WEB. Voyons donc comment faire ce type de chose avec la dernière Form API de Drupal 6.

Déjà pourquoi utiliser gedit plutôt que gTodo ou évolution ? Principalement pour deux raisons : la première est que n'étant pas un directeur de projet, je n'ai à traiter que des "petites" tâches du genre liste de courses, personnes à contacter dans la semaine, etc. La seconde est que gedit est en passe de devenir ma plate-forme de travail privilégiée m'offrant un environnement presque équivalent à kile, de faire des scripts, de travailler sur du html/php ...

Le but de ce tutoriel est donc de réaliser cela en apprenant au passage à fabriquer soi-même une coloration syntaxique adaptée.

Aujourd'hui la majorité des grandes distributions est passée à l'encodage UTF-8, permettant l'affichage propre d'un large panel de symboles linguistiques. Maintenant lorsqu'il s'agit de vieux systèmes mis à jour, ou quant l'on en vient à utiliser des fichiers provenant notamment du monde Windows, il peut être utile de savoir comment unifier les encodages de sorte à garder un système de fichier propre.

Sans grosses trompettes, ni fanfares, avec Drupal 6 est apparue Schema API, une batterie de fonctions dédiées à la gestion des schémas en base de données qui change réellement la vie.

Cette boîte à outils ne contient que ce qui est spécifique à Drupal et ne touche à l'environnement de développement à proprement parler.

Cette boîte à outils ne contient que ce qui est spécifique à Drupal et ne touche à l'environnement de développement à proprement parler.