Drupal 8 : retour d’expérience

drupal-8

Sorti par Acquia fin novembre 2015, la très attendue version 8.0.0 du CMS Drupal est une release commerciale stable, mais souffrant toujours de certaines lacunes. Un projet « Proof Of Concept » vendu à de nos clients nous a permis d'explorer ce nouvel outil en relevant quelques défis posés par un cadre fonctionnel relativement exigeant.

Cet article ne sera donc pas un tutoriel de prise en main de Drupal 8 mais plutôt une analyse technique des points forts / points faibles de la nouvelle version du CMS qui se limitera à l'utilisation que moi et Stéphane Gillot en avons fait durant environ un mois de travail. Nous ne listerons donc pas les modules et différentes fonctionnalités de Drupal 8 de manière exhaustive.

Drupal et Symfony 2, un mariage prometteur

Pour ceux qui l'ignorent encore, l'architecture de Drupal 8 utilise, implémente et étend un grand nombre de composants Symfony 2. Voici une liste de ceux que nous avons le plus utilisés dans le cadre de ce POC :

  • Le routing : permet de générer des URL « propres » pointant sur des actions de controller (oui oui, il y a des controllers dans Drupal 8) ;
  • Les entités Doctrine 2 : la couche d'abstraction de base de données ;
  • HttpFoundation : le fameux composant SF2 permettant une gestion complète des requêtes HTTP ;
  • Twig : le très célèbre moteur de template développé par SensioLabs ;

Il va sans dire que ces composants sont extrêmement fiables et aboutis. Et c'est ce qui fait la force de Drupal 8 : un cœur et une architecture solide. Là où son prédécesseur bénéficiait d'une architecture que la plupart des développeurs PHP frameworks juge contraire aux bonnes pratiques du langage, Drupal 8 s'avère être un vrai framework MVC : controllers, templating, ORM, tout y est. Ce qui le rend donc adapté, sur le papier, à n'importe quel besoin spécifique. Le mimétisme est poussé jusqu'à l'architecture des modules calquée sur celle des bundles de Symfony 2.

D8-SF2

Module Drupal 8 / Bundle SF2

On note la présence de classes supplémentaires côté Drupal. Ces fichiers servent notamment à rendre les éventuelles entités spécifiques au module administrables depuis l'interface backoffice, pratique. Ils sont générés automatiquement lorsque l'on crée un module en ligne de commande. Ce qui nous amène au prochain sujet de cet article : mesdames et messieurs, faîtes place pour la Drupal Console !

Drupal Console : votre meilleure amie

Qu'on se le dise, Drush c'est fini ! Même si Drupal Console ne fait pas partie intégrante de Drupal 8, il est nécessaire d'en parler tant cet outil a favorisé notre progression. Ce binaire permet de faire absolument tout : purge des caches, génération de modules et d'entités, export de configuration backoffice au format YAML, export de bases de données, installation de modules contrib, installation de thèmes, etc. Et tout cela bien évidemment adapté à une application multi-sites.

Ici également on note des similitudes avec la ligne de commandes Symfony 2, notamment au niveau de la génération de modules et d'entités. Dans ces cas de figure, Drupal Console fournit une interface permettant la saisie de différentes informations : nom du module, description, ou la création d'un fichier composer.json pour la gestion d'éventuelles dépendances.

drupal-generate-module

Création d'un module Drupal 8 en CLI

SF2-create-bundle

Création d'un bundle SF2 en CLI

 

 

 

 

 

Ces différents éléments (composants SF2, Drupal Console) fournissent un cadre de travail de base fiable permettant la mise en place rapide de sites Web relativement simple. En revanche on va voir que dans la pratique, l'état de l'art de Drupal 8 pose certaines difficultés.

Des modules « contrib » pas toujours au point

L'un des points forts de Drupal 7 réside dans sa communauté et dans les modules développés par les utilisateurs du CMS. Cet éco-système permet aux développeurs de ne pas ré-inventer la roue, de mettre en place des fonctionnalités avancées très simplement : multi-domaines, géolocalisation, texte enrichi, création de formulaires, indexation de contenu via Apache Solr etc.

Or, Drupal n'étant sorti que récemment, le portage de certains modules majeurs de D7 vers D8 n'est pas effectif à ce jour. Prenons un exemple concret : le principe de Drupal est de stocker un maximum de configuration en base de données. On a vu plus haut qu'il est possible d'exporter cette configuration dans des fichiers YAML. Dans le monde de Drupal, la frontière entre configuration et données est fine. En effet, un menu de navigation créé en BO est considéré comme une donnée, il ne sera donc pas possible de l'exporter en tant que configuration, problématique donc. Le module deploy doit permettre d'exporter des données, mais l'installation de ce dernier nous a posé énormément de problèmes d'instabilité, et nous l'avons jugé inutilisable.

Pour déployer un menu de navigation, pas d'autre choix que d'effectuer la manipulation « à la main » sur les différents environnements. Quand vous devez gérer un environnement de développement, de recette, de pré-production et de production, nul besoin de vous expliquer le côté chronophage du problème.

Autre module majeur : Domain Access. Ce dernier permet la création du multi-sites sur une même installation Drupal (base de données unique), et gère la distinction de la provenances des données et des utilisateurs des différents sites disponibles sur une même installation. Ici, le portage de ce module sur D8 ne semble même pas être en projet. Mettre en place du multi-sites tout en détectant la provenance de leurs données respectives relève donc à l'heure actuelle du bricolage.

Export de configuration vs. travail en équipe

Une grosse partie du développement Drupal est constitué par de la configuration en backoffice, et il est désormais possible d'exporter cette configuration dans des fichiers YAML via Drupal Console ou directement depuis l'interface d'administration. Très bien sur le papier, mais il s'avère que superposé à un modèle de branche tel que Git Flow, que nous utilisons au pôle CMS, la pratique n'est pas si simple.

GitFlow

Modèle de branches préconisé pour l'utilisation de Git

Le principe est le suivant (on admet que deux développeurs travaillent en parallèle sur une même branche) :

  1. Un développeur A crée une vue Drupal (avec le module Views, désormais intégré nativement à Drupal 8), et l'exporte en YAML, puis commit et push ces modifications sur le dépôt ;
  2. Un développeur B crée de son côté une autre vue Drupal, met son dépôt à jour, et importe la configuration envoyée par le développeur A. Il disposera donc de la vue créée par le développeur A, mais aura perdu la totalité du travail qu'il n'aura pas pris soin d'exporter.

Il est bien clair que le problème vient ici d'un manque de maîtrise du système par l'équipe, ce qui traduit une nécessité pour la prise en main de Drupal 8 : accepter de sortir de sa zone de confort et apprendre de nouvelles façons de travailler. De plus, on a pris l'exemple d'une équipe de deux développeurs travaillant sur une seule branche. Imaginez maintenant une équipe plus large et plusieurs branches features développées en même temps qu'il faudra par la suite merger dans une release, en plus de la problématique d'export de données dons nous parlions plus haut : un vrai casse-tête !

Bilan

Drupal 8 est donc, en l'état, un outil stable et puissant permettant la mise en place de sites Web aboutis. Il devra cependant gagner en maturité au travers des modules contrib développés par la communauté pour devenir une solution client réellement efficace. De plus, les équipes l'utilisant devront se confronter à de nouvelles techniques collaboratives et perdront certainement en productivité lors des périodes de prise en main de l'outil.

Enregistrer

Enregistrer

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.