Des griefs toujours présents 2 ans après ...

Nous l’évoquions précédemment, Drupal n’est pas exempt de défaut, loin de là. La keynote de Vienne a été l’occasion de revenir sur un certain nombre de griefs portés à l’encontre de la solution. Parmi-eux, l’éternelle question de l’usabilité du back-office.

« Un back-office complexe et peu agréable »

L’interface « Back-Office » est, disons-le, un peu datée et moins engageante que sur d’autres solutions du marché. Lorsqu’on voit qu’il est possible de créer des applications web légères, ludiques et faciles à prendre en main comme Trello, on se dit qu’un dépoussiérage du Back-Office de Drupal 8 est nécessaire, d’autant plus que celui-ci n’a pas subi de grands changements entre la version « 7 » et « 8 » … (à part le quick edit mais qui existait déjà sous forme de module).

Acquia semble avoir opéré un vrai changement de politique en engageant un Designer UX / UI en tant que « core Product manager ». Roy Scholten travaille déjà sur des concepts qui devraient être intégrés dès la 8.5. (Mars 2018) et que nous présentons un peu plus loin. Un billet posté par Dries début octobre précise par ailleurs, « l’adoption » de React, une bibliothèque Javascript très puissante, que l’on retrouve notamment sur Facebook, Netflix, AirBNB. Dries suggère plusieurs cas d’utilisation de cette librairie, y compris dans le cadre de l’amélioration de l’expérience Back-Office.

On espère que le travail fourni sera à la hauteur de la promesse car il s’agit d’une attente formulée depuis des mois par la communauté et qui ne semble pas entendue pour le moment alors qu’il s’agit pourtant d’un critère de décision qui a un véritable impact dans le choix puis l’appropriation d’une solution au détriment d’une autre.

 « Un back-office freiné par la philosophie du moins-disant »

La philosophie de Drupal a été de limiter jusqu’à très récemment les possibilités offertes avec le « noyau » afin de ne pas surcharger la solution de fonctionnalités inutiles dans le cadre de certains projets (Workflow, Multilinguisme). Ce choix était une volonté délibérée de différenciation des solutions concurrentes, qui chargent tous les modules en BO, rendant l’interface de gestion lourde au niveau fonctionnel et en termes de performances.

 L’idée de base était pertinente, même si on pouvait regretter quelques mesures extrémistes : la gestion des médias ou encore l’éditeur WYSIWYG ne venaient pas avec la solution et nécessitaient une installation manuelle qui pouvait inclure parfois la mise en place de plusieurs modules dépendants.

 Aujourd’hui, le rapport semble s’inverser, du moins pour les fonctionnalités les plus utiles (que l’on retrouve sur la majeure partie des CMS du marché) et / ou utilisées par la communauté (et qui sont régulièrement installées avec Drupal).

 Certaines d’entre-elles sont incluses ou en voie d’intégration dans le noyau de Drupal 8 : l’éditeur WYSIWYG (8.0), la gestion des blocs via une approche WYSIWIG (8.2), la gestion de la publication / dépublication automatique (8.3), la gestion des workflows (8.3 – 8.4), la gestion des médias (8.4 – en partie), la gestion des pages via une approche WYSIWIG (8.5) ou la gestion des workspaces (8.5)… ce qui donne à Drupal une vraie «consistance» dès son installation. Cela permet aussi aux utilisateurs novices d’être moins perdus lorsqu’ils utilisent pour la 1ere fois la solution : ils n’ont plus l’impression que la solution est incomplète.

N’oublions pas enfin que le choix du « bon » module peut rapidement devenir pour un utilisateur peu averti un véritable parcours du combattant, Drupal disposant parfois de plusieurs modules différents (et pas tous à conseiller) pour couvrir une fonctionnalité.

Une migration toujours compliquée depuis D7 ou D6

Drupal 8 a ouvert la porte à la simplification, mais cette évolution n’est pas rétroactive pour les utilisateurs qui étaient en D6. Ne bénéficiant plus du support sur cette version, ils doivent migrer « au plus vite » vers Drupal 7 ou Drupal 8.

Même constat pour ceux qui sont actuellement en D7. Même si cette version bénéficie toujours d’un support technique performant, les choix techniques de Drupal 8, les futures avancées technologiques ou encore la longévité attendue du produit peuvent rassurer bon nombre d’utilisateurs.

Dans la réalité de nos projets, les chemins de migration de D6/D7 vers D8 restent compliqués et surtout limités. Cette migration reste conditionnée par la refonte des différents gabarits du thème, par la nécessité, pour les modules pas (encore) portés, de les redévelopper ou de trouver des alternatives.
En résumé, elle doit être considéré plutôt comme une refonte.

Gageons que la migration de D8 vers D9 soit aussi « facile » qu’annoncée et qu’elle s’apparente à la même difficulté que de faire la mise à jour d’une version mineure comme Dries l’a encore récemment promis.

« Un rythme de mise à jour plus cadencé »

La nouvelle architecture technique de Drupal 8 a permis de modifier les cadences de mises à jour du noyau avec deux cycles :

  • 1 version par mois (8.3.x, 8.3.y…) qui correspond à la correction de multiples bugs sous forme de patchs
  • 1 version mineure (8.3.0, 8.4.0…) programmée environ tous les 6 mois

Quant aux mises à jour des modules, précisons qu’elles sont indépendantes de celles du noyau puisque ces dernières sont gérées directement par son mainteneur. Les notifications de mises à jour se font directement dans le back-office de la solution tout comme l’installation de la version «upgradée».

updates-drupalcon-vienne_2017.pngSource : Slideshare

 

Le risque d’automatiser les mises à jour

La communauté s’est exprimée sur la possibilité d’automatiser les mises à jour, notamment « critiques ». Cette demande, au-delà de sa faisabilité technique, nous laisse une impression plutôt mitigée. Car même si les failles non corrigées rapidement peuvent nuire au site et à la réputation du CMS, la mise à jour automatique d’un CMS ou d’un OS peut entrainer une instabilité du système, voir dans certains cas un crash.

 Il est donc nécessaire, selon nous, de les maîtriser en respectant un certain processus (par exemple faire un back-up préalable du site et de la base de données) par des profils qui ont une expertise technique, ne serait-ce que pour corriger éventuellement le tir en cas de dégradation.

 Afin de trouver un juste milieu, une réflexion de fond est menée par les équipes de Drupal pour automatiser un certain nombre de mises à jour. Un déploiement en plusieurs étapes potentielles qui couvrira un périmètre de plus en plus grand, allant des patchs de sécurité, des modules contrib, des patchs release, jusqu’aux versions mineures. Il s’agit cependant d’un chantier très structurant et techniquement difficile dont les bénéfices ne sont pas attendus avant plusieurs versions.

Du renouveau avec la 8.5 et la 8.6

La DrupalCon de Vienne a été l’occasion de présenter de nouvelles fonctionnalités, dont certaines arrivent dès la prochaine version en mars 2018 (sortie de Drupal 8.5). Petite présentation (que vous pouvez aussi découvrir en vidéo ici : https://youtu.be/viNU2wOKIUk?t=2874).

« Layout Builder » : La (très) bonne surprise de la 8.5

Il a bien sûr toujours été possible de créer des pages dans Drupal 8 mais le processus proposé n’est pas très ludique, surtout comparé à ce qu’il était possible de faire sur Drupal 7 via le module Panels

Avec la sortie de la 8.2, Drupal a corrigé en partie le tir en proposant le module « Bloc Builder » qui permet, comme son nom l’indique, de positionner différents types de blocs (action, formulaires, aides, remontées de contenus récents…) au sein d’une même page.

 En version 8.5, Drupal va élargir ce mécanisme aux pages : Il sera possible de définir des sections au sein d’une page puis d’associer pour chacune d’entre-elles différents colonages :1 colonne, 2 colonnes, 3 colonnes (25% /50 % /25 % de la page), 3 colonnes (33% /34 %/33% de la page).

capture-backoffice-drupal

 

capture-backoffice-drupal2

 

Chaque colonne pourra, comme disposer de plusieurs types de blocks, positionnés selon les mêmes modalités que sur la 8.2. Une nouveauté reste cependant à signaler : il sera possible de déplacer un bloc d’une zone à une autre par simple drag and drop.

capture-backoffice-drupal3

 

capture-backoffice-drupal4

 

capture-backoffice-drupal5

 

« Les Workspaces » pour faciliter le déploiement du site d’une plateforme à une autre (prévu dans Drupal 8.5)

La notion de workspaces est-elle aussi planifiée dans la 8.5. Elle permet de déployer rapidement et simplement des contenus d’une plateforme à une autre. Concrètement, il sera facile de « pusher » des éléments (page, contenu, menu, taxonomie, utilisateur…) d’une plateforme de préproduction à une plateforme de production par simple sélection.

capture-workspace

 

En regardant la vidéo au ralenti (à partir de https://www.youtube.com/watch?v=viNU2wOKIUk&feature=youtu.be&t=2874) , on remarque deux choses intéressantes :

  • Il est possible de comparer deux versions d’un même contenu (par exemple la version locale et la version en prod) …
capture-backoffice-drupal6
  • Le déploiement semble prendre en compte la notion de dépendance. Pour simplifier, si vous poussez un contenu qui comprend des éléments liés comme des images, des documents, un bloc ou une taxonomie spécifique… le système saura repérer le ou les chainons manquant(s) et les pousser par la même occasion sans que vous ayez forcément à l’indiquer.

Nous avons hâte de pouvoir tester cette fonctionnalité très attendue par nos équipes mais aussi par nos clients qui disposent pour certains de plusieurs serveurs à mettre à jour.

Media Library dans le noyau (planifié dans Drupal 8.5 et 8.6)

La gestion des médias dans le noyau de Drupal 8.4 représente une avancée par rapport aux versions précédentes mais qui reste encore très sommaire car elle nécessite l’intégration manuelle de plusieurs modules complémentaires (media entity, Entity Browser ou encore Dropzone.js) de la suite Media pour bénéficier d’une solution qui tienne la route.

Quelques ajouts sont attendues dans Drupal 8.5 et Drupal 8.6 dont l’intégration d’un média dans l’éditeur WYSIWIYG. Il est d’ailleurs possible de suivre les demandes sur https://www.drupal.org/core/roadmap et plus particulièrement sur https://www.drupal.org/core/roadmap#media (attention, certaines demandes peuvent passer à la trappe ou être reportées)

Publié par Adimeo
CEO Adimeo
Retrouvez moi sur :

Un conseil, un projet, un devis ?
Nous repondons a toutes vos questions !

N'hésitez pas à nous contacter pour plus d'informations

Nous contacter

Sur les mêmes sujets