Classé parmi les [meilleurs gestionnaires de contenus open-source->http://www.packtpub.com/2007-open-source-cms-award-finalists], Drupal suscite actuellement un très fort engouement et les références se multiplient (AOL Developer Network, Fox Searchliight, Warner Bros , Amnesty International, …).
Oui mais …
Drupal
Les premiers pas avec Drupal sont très prometteurs. De base, une mise en page sobre et épurée. Drupal est réalisé de manière extrêmement modulaire (trop peut-être). D’emblée, Drupal est fourni avec une trentaine de modules. Seulement un quart de ces modules sont actifs par défaut. La moindre fonctionnalité est vue comme un module, et non comme une partie du noyau de base. Le fait de pouvoir créer du contenu est un module en lui même ! Mais il est obligatoire, on le comprendra ! L’outil de recherche, les menus, les commentaires sont également vus comme des modules distincts.
Et si on n’en a pas assez, on va se délecter sur le site communautaire drupal.org pour aller télécharger l’un des 2442 modules (je les ai comptés !) et l’installer très simplement. Evidemment, devant un tel volume de modules, il vaut mieux se faire aider initialement par une personne plus expérimentée qui nous recommandera certaines solutions en fonction de nos besoins.
Un autre point fort de Drupal, le site communautaire. D’une part, il est bien organisé : on trouve rapidement le module que l’on souhaite, et on identifie rapidement la ressource à télécharger en fonction de la version de Drupal. D’autre part, le site est très riche, et la communauté très active. La recherche avec Google (que ce soit pour résoudre un problème ou pour chercher une information) nous renvoie quasi-systématiquement sur le site communautaire. Seul bémol : le site est lent, victime de son succès (bien qu’il ait un peu progressé ces dernières semaines).
L’une des fonctionnalités les plus intéressantes de Drupal est selon moi le typage des contenus (module CCK). Cette fonction permet de créer toute sorte de contenus, d’ajouter toute sorte de champs, basiques, numériques, dates, énumérés, etc… Elle permet également de dire quels champs on souhaite afficher en fonction du mode (affichage article complet, affichage article résumé, affichage liste, …).
Une autre fonctionnalité très intéressante est fournie par le module Views, permettant d’une part de sélectionner un ensemble de contenus suivant des critères élaborés, et d’autre part de les afficher sous la forme que l’on souhaite.
Drupal permet d’aller relativement loin dans la conception d’un site sans avoir à ouvrir son éditeur PHP favori. Les fonctions citées ci-dessus ne nécessitent aucune ligne de code. L’agencement des blocs se fait également par l’interface, au travers de plusieurs zones prédéfinies, et si le nombre de zones ne suffit pas, on peut éventuellement reposer sur le module Panels fournissant des layouts supplémentaires. On peut également choisir sur quelles pages tel ou tel blocs s’affiche, simplement via l’interface.
Quelques autres points intéressants :
– gestion multilingue (par contre pas tout à fait au point pour certains modules)
– La réalisation de modules est facile, car l’API Drupal fait la plupart du travail. Avec juste quelques lignes de code on peut obtenir une interface de module settings complètes, un mécanisme de validation des réglages, un mécanisme d’install/uninstall, …
Or not Drupal
Le theme (terme officiel de Drupal pour gabarit, template, layout, squelette, …) repose sur phptemplate. Sur le principe, puissant car en théorie on peut tout faire. Cependant, la thématisation nécessite des compétences php poussées car elle repose sur la reflexion et sur une surcharge sur plusieurs niveaux de certaines méthodes[[Pour la mise en page de données, la méthode montheme_fct() va être recherchée. Si elle n’est pas trouvée, la méthode phptemplate_fct() va être également recherchée, puis la méthode theme_fct(). Cela offre de nombreuses possibilités d’insérer sa fonction, mais rend difficile la « lecture » d’une méthode car il faut sans cesse recherche les méthodes existantes. De plus, ces fonctions embarquent souvent une part importante de logique, en plus de la mise en page. ]]. Du coup, il n’est pas du tout facile de naviguer dans le code.
Chaque module gère lui-même le code html généré. Lorsque l’on souhaite modifier la mise en page (ce qui arrive dans la plupart des cas), il faut donc analyser le code php du module pour comprendre où est-ce qu’il génère le code html, voir s’il y a certaines méthodes surchargeables, s’y insérer si c’est le cas, voir modifier le code des modules. Les structures manipulées sont souvent très lourdes, peu intuitives.
La thématisation/réécriture de formulaires tels que le bloc de recherche ou le bloc d’authentification est également une sinécure, en raison d’un procédé complexe mis en place en partie pour éviter le cross site request forgery[Drupal injecte une clé unique dans les formulaires, et lors de la validation, vérifie la présence de cette clé. Il s’agit d’une très bonne pratique pour limiter les failles de sécurité. Cependant, ce mécanisme est enveloppé dans un processus de redirection. Du coup, une simple modification sur le rendu de certains blocs peut demander des compétences Drupal poussées.]].
Bref, pour moi, la mise en page est le très gros point noir de Drupal.
Un autre inconvénient très pénalisant est l’intégration des modules entre eux. Certains modules fonctionnent, mais déstabilisent les autres ou cohabitent mal (module [Category à éviter par exemple). D’autres modules n’étendent pas leur champ d’action aux autres modules installés. Ceci en raison d’une conception de base sans doute pas idéale, c’est à chaque module d’interroger la présence des autres modules. Parfois, un module se « met à ne plus marcher », du moins à se comporter de manière non nominale, et la recherche de la cause devient extrêmement difficile : est-ce un module récemment installé qui déstabilise ? un contributeur qui a fait une boulette ? la base qui a été corrompue ? un cas non prévu dans notre code ?
Autres points négatifs :
– il n’y a pas d’organisation interne du contenu, tous les contenus sont affichés à plat.
– gestions des fichiers/media pauvre (pas moyen de créer des sous-répertoires pour organiser ses images et autres fichiers, notions d’espace privé et d’espace public mal gérés au niveau des droits d’accès aux images/pièces jointes)
That is the question
Drupal est un CMS très attrayant, de part le nombre des modules proposés et l’activité de sa communauté. Cependant, le choix de Drupal doit être accompagné par l’intervention d’experts de ce CMS pour en éviter les pièges, notamment :
– L’architecture du projet sur Drupal ne doit pas être mis entre les mains de novices. Malgré l’apparente facilité d’obtenir n’importe quelle fonction en installant l’un des nombreux modules, on peut se rendre compte tardivement que l’intégration de l’ensemble est bâtie sur des pieds branlants.
– La mise en page « fine » est très délicate et demande une bonne maîtrise de structures de données PHP complexes. Attention donc au choix de Drupal pour des sites à charte graphique stricte (contrainte d’accessibilité, charte non ajustable, …)
Charles Népote
25 janvier 2008
Bien vu.
« Bref, pour moi, la mise en page est le très gros point noir de Drupal. »
Pour être plus précis, c’est « la fabrication d’un gabarit » qui est une difficulté. En utilisant l’un des très nombreux gabarits existants, la mise en page est plutôt simple et riche, comme tu l’as souligné.
Christophe C
28 janvier 2008
@Charles> « Pour être plus précis, c’est « la fabrication d’un gabarit » qui est une difficulté. En utilisant l’un des très nombreux gabarits existants, la mise en page est plutôt simple et riche, comme tu l’as souligné. »
Un peu comme WordPress, Joomla, Spip, etc. Une offre qui parait forte alléchante et concurrentielle, mais qui au final se révèle être pour des professionnels ayant une expertise au delà du simple bidouillage.
Tristan Marly
28 janvier 2008
Oui, effectivement, l’utilisation d’un gabarit existant est pratique mais rarement acceptable dans un cadre professionnel lorsqu’il y a une charte graphique bien définie.
Cependant, je le distinguerai nettement de Spip dans le sens où Spip est de bas niveau, c’est à nous de développer l’interface, alors que Drupal est de haut niveau, fournit des composants existants, et notre travail est alors de modifier ces composants pour qu’ils ressemblent à ce que l’on souhaite.
Sur l’approche purement mise en page, je préferre de loin Spip.