Drupal un CMS ?

De plus en plus de site migrent vers Drupal, j’ai voulu donc voulu voir ce qui poussait les gens à utiliser cet outil. Après plusieurs tests, mon avis à ce sujet est mitigé.

Drupal out-of-the-box ne contient pas grand chose, tout se passent par l’ajout de module. Ce concept me semble dans un premier temps intéressant, mais c’est la que les premiers problèmes commencent. Il faut trouver des composants pour chaque tache.

Les types de données sont limités, on trouve au départ des types pour écrire des articles, des pages et des livres. Ils ne comportent pas grand chose, généralement un champ texte pour le titre, un bloc “riche” pour le contenu, des mot-clés.

Les principaux concepts

Les nœuds

Dans Drupal, tous les contenus sont des nœuds. Il est donc possible d’étendre le modèle de base en utilisant l’identifiant du nœud pour créer son propre modèle de données et d’y attacher des données connexes.

Les taxonomies

Ce sont des ensembles de mots clés pouvant avoir différentes structures (à plat, hiérarchique sous forme de graphe). On peut associer à chaque nœuds un ou plusieurs termes de chaque groupe taxonomique.

Les modules

Les modules sont l’ensemble des codes tierces que l’on inclut dans la logique applicative de Drupal. Ils sont écrits en PHP.

Les blocks

Les blocks sont des petits fragments de html qui sont inséré dans une page Web.

Les thèmes

Ni les nœuds ni les modules ne s’occupent de la présentation, ce sont les thèmes qui s’occupe de la couche de présentation. c’est à dire du rendu HTML / CSS / JS.

Quelques points intéressants

Édition d’un bloc de texte

Par défaut, le bloc “riche” s’écrit directement en mode texte (ce qui n’est pas pour me déplaire). On peut spécifier différents niveaux de filtres sur les balises HTML. L’insertion d’image dans un contenu est plutôt barbare avec une belle balise img et sa src en dur. Passons, de toute façon, le marché actuel du Web impose l’utilisation d’un éditeur WYSIWYG, la communauté Drupal fournit plusieurs intégrations d’outils classique du marché (FckEditor, TinyMCE). Après plusieurs installations de modules et de leurs dépendances, je dispose enfin d’un formulaire d’édition d’un article un peu plus user-friendly commercial. La qualité des intégrations des éditeurs WYSIWYG varie considérablement d’un module à l’autre. Il faut bien faire attention au choix du module.

Type de données

Pour avoir des types de données, un peu plus élaborés, les diverses documentations me renvoient vers le module CCK permettant de définir des champs peu plus spécifiques. L’installation de ce module ne pose pas de problème particulier, mais la pauvreté fonctionnel de ce module qui n’ajoute qu’une ébauche de virtualisation de données, ne me rassure pas du tout (on est bien loin de ce que propose eZ Publish). Il ne me reste plus qu’une solution c’est de devoir écrire mon propre module pour pouvoir avoir des types de données un minimum structuré.

Les modules

Les modules fonctionnent comme un conteneur IoC. On définit les différents hooks dans le cœur de Drupal pour y injecter notre logique au bon endroit. Les hooks doivent obéir à une convention de nommage, suivant le principe de convention plutôt que configuration. L’idée est bonne, dommage que l’interface proposée n’utilise pas la programmation orientée objet, tout cas sa syntaxe.

Les modules permettent d’enrichir le contenu des nœuds, les hooks fournit permette d’intervenir à tous les niveaux de l’application, que ce soit à la création des nœuds dans l’interface d’admin, la consultation, la suppression, … . Cette partie est plutôt bien faite.

Par contre, l’API fournit par Drupal, bien que fonctionnel, n’est pas des plus riches. La couche de bases de données n’est qu’une encapsulation très simple des fonctions php de base (même pas de PDO), il n’est pas question de mappage relationnel-objet dans cette bibliothèque. Pour les formulaires, l’interface n’est pas des plus intuitives, et correspondent plus à une encapsulation html /js à l’intérieur de fonction PHP.

Modèle MVC

Drupal ne fournit pas d’implémentation d’un modèle MVC. La séparation entre le contrôle et le modèle est inexistante, elle est à la charge du développeur. Par contre, on trouve une séparation stricte entre le contenu et la présentation.

Conclusion

Les idées proposées par Drupal sont très intéressantes, elles s’inspirent des meilleurs pratiques de génie logiciel. Cependant, la non-utilisation de la programmation objet est un manque important à l’outil. Le gros point noir de cet outil est la qualité des modules fournit par la communauté qui est vraiment mauvaise. Sur 3 tests avec des modules différents, je me suis 3 fois avec une base de données où les données sont complètement corrompus. Pour un développement professionnel, on est obligé de systématiquement développer ses propres extensions.

Drupal en tant que CMS n’est pas une solution pour des sites importants, avec des contenus très structurés. Par contre, comme gestionnaire d’article, c’est un outil redoutable qui remplace des outils comme SPIP, Joomla! ou Wordpress.

A la une
  • Rencontre du numérique 2019 - Nîmes
  • référencement naturel d'un hôtel
  • Développeur eZ Platform
  • Tech lead Symfony
  • Expert Qualité Web

Copyright - Sylvain FIX

2009 - 2019