Franck Canonne, développeur PHP MySQL JavaScript freelance

Drupal (prononcé /ˈdruːpəl/) est un système de gestion de contenu (CMS) libre et open-source publié sous la licence publique générale GNU, et écrit en PHP. Dries Buytaert, développeur initial du projet à partir de 2000 à l'université d'Anvers, le définit comme « assembleur rapide de site web » (Rapid website assembler). Il est utilisable tel que fourni sur toute base LAMP, WAMP ou MAMP, mais largement personnalisable et programmable ensuite. D'après son créateur, environ 500 000 sites l'utilisent en septembre 2009.

Principes

Drupal peut être utilisé à quatre niveaux différents :

1. Tel quel : une fois celui-ci installé et paramétré, il est utilisable pour créer du contenu structuré et annotable par des utilisateurs qui peuvent s'enregistrer sur le site. Les menus du site ont alors un aspect standard.
2. Personnalisation simple : il est ensuite possible de personnaliser l'emplacement d'affichage, ou l'affichage lui-même, de composants visuels standards (date et heure, derniers posts, nombre de connectés, etc.), ainsi que le thème d'affichage (terme expliqué plus bas) du site.
3. Extension par ajouts externes : ajout, paramétrage et personnalisation de modules optionnels n'appartenant pas au noyau. À ce stade et au suivant, il n'est pas rare que le développeur du site écrive aussi un thème de présentation qui lui soit propre.
4. Extension par développement interne : écriture de nouveaux modules régis par la GPL, qu'il est souvent efficace (mais nullement obligatoire) de présenter ensuite à la communauté afin que celle-ci puisse participer à leur évolution.

Drupal lui-même utilise une base de données - comprenant typiquement 60 à 300 tables selon les modules activés - et une hiérarchie de fonctions toutes substituables permettant au développeur d'application expérimenté de réécrire la seule partie qu'il désire modifier, et uniquement au niveau d'abstraction auquel il s'intéresse, sans toucher au reste. La bonne ou la mauvaise connaissance du niveau exact auquel intervenir peut diviser ou multiplier le temps de réalisation d'un facteur 10 ou plus.
Drupal comporte environ 4000 API, mais le site api.drupal.org permet de les retrouver en accès direct par une partie quelconque du contenu de leur nom. Dans la pratique, un module simple peut fort bien n'en utiliser qu'une dizaine, voire moins.

Nœuds, fonctions de métier, fonctions de présentation

Nœuds : désignent les contenus
Drupal nomme tout contenu qu'il gère un "nœud". Une page d'article sera par exemple un nœud. Une page de livre aussi.

Ce nœud possèdera d'une part un type : forum, article de fond, information brève, tutoriel, blog, commentaire, formulaire de saisie, livre collaboratif, image ou galerie d'images, sondage interactif, page de wiki, etc. : la forme n'est plus assujettie à une architecture prédéterminée, ce qui rend le contenu aisément reconfigurable. Contrepartie de cette liberté : on doit se familiariser avec sa logique particulière.

Le nœud possèdera par ailleurs, conformément aux spécification de son type, des champs : nom, type, date, auteur, image éventuelle, corps, votes de la communauté sur son contenu, etc.

Chaque nœud peut être attaché simultanément à plusieurs termes taxinomiques si on le désire (ainsi une brève sur une médaille d'or française aux Jeux olympiques peut être rattachée à la fois à "Sport" et à "France"). Le concepteur ou l'administrateur ne sont donc pas obligés d'insérer leurs contenus dans une hiérarchie initiale unique. Il faut simplement que les taxinomies restent cohérentes (A ne peut pas dépendre de B dans l'une pendant que c'est B qui dépend de A dans une autre, ce qui n'aurait de toute façon aucun sens).

À sa création, un nœud se voit attribuer un node ID (NID) qui le caractérise. Au fur et à mesure de ses révisions, s'il y en a, le système incrémentera un compteur de revision ID (RID). Le concepteur peut choisir de conserver ou non les révisions autres que la plus récente. Chaque nœud possède aussi un titre, ce qui permet aux administrateurs de les gérer de façon plus commode.

Le système de révisions successives permet de revenir à une version antérieure si besoin, comme on le fait dans les wikis.

Fonctions de métier : programmes PHP de traitement

Il existait dans Drupal 6 plusieurs types de modules, les plus simples étant les suivants :

• les modules de bloc, associés à des informations de petite taille (exemple : qui est en ligne ou combien de personnes, qui sont les derniers inscrits, quels sont les derniers posts, les plus populaires...). Leurs résultats s'afficheront en marge des "grands" contenus, dans des marges de droite, gauche, haut ou bas.
• les modules de nœud, qui engendrent ce qui n'est pas dans les marges : blog, forum, pages, formulaires, etc. Quatre simili-méthodes leur sont associables en standard : list, configure, save et view, qui indiquent respectivement comment le module doit signaler son existence, comment le configurer, comment sauver cette configuration et comment ce module affichera ses informations.

Dans Drupal 7, cette différence disparaît : il n'existe plus que des zones que l'administrateur du site peut déplacer à tout moment comme il le veut, et auxquelles le thémeur ou concepteur attribue des tailles, des polices et des teintes. Le contenu d'un noeud peut donc parfaitement s'afficher dans les marges latérales si nécessaire, etc.

Les fonctions d'un module peuvent renvoyer trois choses :

un code d'erreur

• rien, ce qui constitue un autre type d'erreur (WSOD : White Screen Of Death)
• un vecteur ou un tableau (voire un tableau de tableaux) au sens de PHP. A ce niveau, il n'y a en principe encore aucune balise XHTML injectée. C'est le thème qui s'en chargera.

Fonctions de thème : homogénéité de présentation

Ni les nœuds ni les modules ne s'occupent de la présentation (ni même d'ailleurs de balises XHTML). Ce sont les styles qui en sont chargés, à la manière des feuilles de style en (X)HTML. Un administrateur de site Drupal peut changer profondément le style avec quelques clics de souris.

Ce système est conçu pour bien séparer le cœur de métier d'un créateur de site (gestion et articulation des données) de la partie uniquement cosmétique, qui fait appel à des concepts bien distincts (ergonomie entre autres) et peut avoir avantage à être sous-traitée totalement à une officine spécialisée.

Il est géré partout où cela est possible par des entrées dans une CSS et, là ou du traitement spécifique est nécessaire (par exemple alterner deux couleurs de fond pour présenter les lignes successives d'un tableau) par des fonctions de thémage simples écrites en PHP.

Les fonctions de thèmage prennent en entrée des chaînes, vecteurs ou tableaux (ou tableaux de tableaux) et produisent en retour une chaîne XHTML de mise en forme qui sera dirigée par le programmeur vers la zone de son choix, désignée par son nom et non par sa position. Le concepteur et l'administrateur du site décident en dernier ressort des endroits de la page, couleur et police où s'afficheront ces informations, et cela soit par réorganisation de blocs au tableau de bord, soit par modification des feuilles définissant le style de chaque bloc.

Administration des blocs

À un module de bloc sont associées des informations définies et modifiables extérieurement au module par l'administrateur

• une information de placement (haut, bas, droite, gauche...),
• une information de priorité (en général de -10 à +10) par rapport aux autres blocs ayant la même indication de placement,
• et une information indiquant si ce bloc est activé (=doit être affiché) ou pas.

Cette composition est voisine de la box strategy définie par Donald Knuth pour rendre cohérente la composition d'ouvrages en PAO

Depuis la version 6, les informations de priorité sont gérables par simple glisser/déplacer sur un menu spécial, ce qui facilite les réarrangements fréquents.

A partir de la version 7, il n'y a plus de blocs latéraux opposés à une partie centrale, mais uniquement des régions gérées sur un pied d'égalité par l'administrateur. Ainsi une fenêtre de débogage latérale peut être déplacée d'un clic dans la partie centrale plus vaste le temps d'un développement, etc.

Programmation évènementielle
Drupal associe des exécutions de code à chaque objet cliquable (callbacks). Ce qui est développé ne possède donc pas de séquence à proprement parler, et peut être appelé dans un ordre quelconque.

Les fonctions de callback en Drupal sont voisines conceptuellement de la notion de tâche en CICS, à ceci près que la phase de compilation n'a plus lieu d'être, PHP étant un langage interprété.

• Dans les deux cas, l'application se modifie donc à la volée sans nécessité de l'arrêter;
• En revanche, avec Drupal, il faut faire attention à n'activer (="ne faire prendre en compte par Drupal") un module que si celui-ci est syntaxiquement valide (qu'il soit fonctionnel ou non), sans quoi c'est toute l'application qui provoque une erreur. Cela ne pose cependant pas de problème si on travaille depuis un environnement de développement intégré, genre Eclipse, Zend Studio, etc., où l'on ne sauvegarde en principe pas le programme en cours tant que sa syntaxe n'est pas validée dans l'environnement éditeur.

Rôles

L'administrateur peut affecter à chaque utilisateur (existant ou par défaut pour chaque futur utilisateur) un ou plusieurs rôles, qui regroupent un ensemble de permissions. Il est alors possible de définir finement autant de permissions que nécessaire entre l'administrateur - qui peut tout faire - et l'usager non enregistré, qui peut par exemple n'avoir le droit que de regarder le site sans le modifier.

• On peut par exemple créer les rôles de validateur de contenu (qui approuve et/ou modifie les contenus soumis pour publication), de validateur de commentaires (qui n'a ces fonctions que sur la partie commentaires), etc.
• On peut aussi décider que les utilisateurs non-connectés ne pourront utiliser que le format mediawiki pour entrer leurs textes, tandis que les abonnés au service auront le droit au XHTML total ou partiel avec entrée WYSIWYG, etc.

Le contenu est roi

D'une version majeure à la suivante (4.x, 5.x, 6.x, ...) Drupal ne garantit nulle compatibilité ascendante du code développé, mais en revanche garantit qu'il ne sera jamais besoin de modifier le contenu, qui représente souvent de cent à mille fois le volume du seul code (il se prête donc bien aux contenus nécessitant une forte pérennité : consultation d'archives de presse, de textes légaux, de suivi de clientèle, etc.).

(Note : Cette décision qui peut surprendre est liée à l'évolution très rapide des pratiques sur l'Internet : un CMS qui serait astreint aux restrictions d'une analyse et d'une architecture pensées deux ans plus tôt ne serait plus forcément en phase avec les attentes du marché, et ne gèrerait les nouvelles possibilités techniques (vidéo, géolocalisation, Google maps, PDA, Flash, RSS, Twitter, détection d'anomalies de sécurité en temps réel, etc.) que par des sortes de rustines. Or changer de CMS parce que l'ancien est en impasse coute bien plus cher que simplement faire muter de version un CMS existant sans effectuer autre chose qu'un export/import de son contenu)

Pour cette raison, il existe toujours deux versions majeures de code successives maintenues séparément par les équipes de développeurs. On peut donc choisir si on le désire d'ignorer une version majeure sur deux. On peut aussi si on le préfère faire coexister une version de production et une version de test sur un contenu identique, etc.

Dans la pratique, les modifications ne portent la plupart du temps que sur le nombre d'arguments des fonctions existantes (API), les ajouts leur permettant des fonctionnalités supplémentaires. Voici par exemple une évolution de l'API book_toc(), qui établit la table des matières d'un contenu de type livre (ensemble de nœuds structurés) :

• Versions 4.6 à 5 : book_toc($exclude = 0)
• Version 6 : book_toc($bid, $exclude = array(), $depth_limit)  : Contrôle plus fin du résultat
• Version 7 : book_toc($bid, $depth_limit, $exclude = array())  : Permutation pour placer à la fin l'argument facultatif

Architecture

Langage hôte

Drupal est développé en PHP. Il fait aussi usage, mais de façon invisible au programmeur, de nombreuses fonctionnalités programmées en JavaScript, principalement à travers une utilisation transparente de JQuery.

Le code de Drupal obéit à une logique proche d'un développement Smalltalk : la plupart des fonctions sont de taille petite ou moyenne, et composées d'appels à d'autres fonctions de niveau d'abstraction de plus en plus proche des données de base. Ajouter ou modifier du code ne demande donc jamais de descendre à un niveau d'abstraction plus bas que strictement nécessaire.

Composants

Drupal comporte deux types de composants bien distincts :

• un « cœur » fiable et robuste, largement testé
• des « modules » de volume et qualité diverses développés librement par la communauté et mis à disposition de tous en l'état (1800 en mars 2008).

Le cœur est maintenant totalement francisé, ainsi qu'une partie seulement des modules non officiels. Il est aisé de se faire une première idée de la qualité de ces modules, car le site officiel les recense et met en regard de chacun les bogues remontées avec leur date et celle de résolution s'il y en a eu une. Dans la pratique, on ne sera jamais si bien servi que par soi-même, ce qui est le principe même de l'Open Source : les modules sont écrits en PHP ordinaire.

Lorsque l'usage de certains modules est durablement plébiscité, ceux-ci peuvent être incorporés dans le cœur d'une version ultérieure. Celui de Drupal 7 intègrera par exemple la suite de tests automatiques SimpleTests[5], jusqu'à présent module séparé.

Les modules sont composables entre eux pour en donner de plus puissants. Un exemple typique est OG Minutes, qui combine le module OG (organic groups gérant des communautés privées ou publiques d'utilisateurs), et Minutes (gérant les présences à un meeting), etc.

Récompenses

Aux États-Unis, Drupal s'est classé premier au concours du meilleur CMS[6] 2007, dans la catégorie 2007 Overall Open Source Content Management System Award (Récompense du meilleur système de gestion de contenu en accès libre), second dans la catégorie Best PHP Open Source Content Management System (Meilleur système de gestion de contenu en accès libre et en php, derrière Joomla!) et second au Best Open Source Social Networking Content Management System (Meilleur système de gestion de contenu en accès libre orienté réseaux sociaux, derrière WordPress).
Il a été à nouveau classé premier en 2008 et en 2009.

Caractéristiques

Moteurs de template

Drupal permet d'utiliser comme moteur de template XTemplate, PHPTemplate (moteur de template officiel depuis la version 4.7) mais aussi Smarty.

Permissions

De façon à permettre une souplesse maximale, les permissions sont gérées par des libellés que les administrateurs et rédacteurs de modules choisissent librement. Il faut juste prendre garde à ce que le même libellé ne soit pas utilisé par deux modules différents pour désigner des permissions différentes.