BASE DE DONNÉES DE PUBLICATION ET SYSTÈME DE GESTION DE CONTENU AVEC DRUPAL 6


Mon premier contact avec le CMS remonte à 2012, lorsque j’ai testé la distribution OpenAtrium de Drupal 6 comme solution possible pour un intranet de publication. L’intranet de l’entreprise n’a pas vu le jour, mais j’avais découvert qu’OpenAtrium avait un moteur avec le CMS Drupal sous le « capot » qui pouvait faire beaucoup plus.

L’année suivante, Drupal s’est donc également lancée dans un projet d’édition global : un groupe d’éditeurs a planifié un catalogue semestriel commun de nouvelles publications pour le secteur du livre. A cette fin, les titres à inclure devaient être saisis de manière décentralisée dans une base de données dans chaque maison d’édition et le catalogue imprimé commun devait être produit tous les six mois selon une procédure aussi automatisée que possible. Bien qu’il s’agissait plus d’un projet de base de données que d’un projet de site web, la décision a été prise en faveur de Drupal – principalement en raison des options d’extension associées.

Ces options sont rapidement apparues lorsque l’un des éditeurs a eu besoin d’un système de gestion du flux de travail pour l’inclusion des titres dans le programme de l’éditeur, y compris un processus de révision en ligne correspondant, en tant que « pré-étape » du catalogue qui avait depuis été mis en œuvre.

Ce système pourrait être facilement construit avec Drupal avant l’agrégation des données pour le catalogue professionnel du livre, de sorte que dans le système complet résultant, le parcours complet d’un titre (qui peut durer plusieurs années) pourrait être cartographié depuis les premières considérations internes à la maison d’édition jusqu’à son annonce pour le commerce du livre.

Grâce à Drupal et à une cinquantaine de modules utiles, le temps de développement n’a été que de six mois, et pas une seule ligne de code n’a dû être écrite.

SYSTÈME ÉDITORIAL LEXIQUE AVEC DRUPAL 7

Après les bonnes expériences avec Drupal, le CMS a également été utilisé dans des projets de suivi, mais aussi dans la nouvelle version 7, Drupal 7, par exemple, est utilisé depuis 2016 comme système éditorial pour un projet de lexique avec plusieurs milliers d’articles et plus de 400 auteurs, ce qui a nécessité un workflow à plusieurs niveaux et des autorisations complexes. Une fois que les contributions en ligne des auteurs ont été éditées par la rédaction et approuvées par les éditeurs, elles sont mises à disposition en format XML pour le dictionnaire imprimé de Drupal. Le temps de développement n’a été que de 3 mois, également dans ce cas uniquement grâce à l’utilisation de Drupal Core et des modules appropriés.

DRUPAL 6 À DRUPAL 8


Lorsque Drupal 6 a atteint la fin de sa durée de vie en 2016, le système de gestion du workflow de publication a continué à se développer et plusieurs interfaces ont été ajoutées. Depuis la sortie de Drupal 8 en novembre 2015, la décision a été prise d’ignorer Drupal 7 et de mettre à niveau le système vers Drupal 8 immédiatement. La version Drupal 8 a fait une impression de maturité et de stabilité et il était clair que tôt ou tard le chemin devrait conduire à Drupal 8 de toute façon.

COMPOSITEUR, DRUSH ET YAML

Toutefois, certains obstacles ont dû être surmontés au cours de ce nouveau passage : D’une part, il est rapidement apparu que le développement n’était terminé qu’avec l’utilisation de l’interface Drupal. Sans Compositeur et Drush, ce n’était plus possible. De plus, le contenu de l’installation de Drupal 6 a dû être migré. Les scripts de migration yaml créés avec les modules de migration Drupal ont dû être retravaillés à de nombreux endroits, également pour apporter quelques améliorations à la structure des données au cours de la migration.

Enfin, il s’agissait d’utiliser la nouvelle gestion de configuration de Drupal 8 et de développer un workflow de déploiement adapté. Drupal 8 s’est avéré être un système mature et très stable dont la manipulation est beaucoup plus exigeante qu’avec les versions précédentes, mais qui le rentabilise par des performances et des fonctionnalités étendues.

INTÉGRATION DE MODULES D’EXTENSION

L’intégration de modules externes était plus complexe que dans Drupal 6. Malgré l’inclusion de quelques modules Drupal 6 dans le noyau de Drupal 8, il en restait encore près de 50 qui devaient être intégrés dans la nouvelle solution Drupal 8. En raison des profonds changements techniques de Drupal 8, la personnalisation des modules prenait souvent beaucoup de temps aux développeurs. Dans certains cas – par exemple avec le module Rules utilisé intensivement – il n’y avait (encore) aucune solution de remplacement opérationnelle disponible pour Drupal 8.

Il fallait donc trouver des solutions de remplacement appropriées. Mais même les modules de remplacement (tels que les règles métier au lieu des règles) étaient souvent encore en cours de développement. Par conséquent, des tests approfondis, des rapports de bogues, des correctifs et des correctifs ont été nécessaires. Alors que l’installation originale de Drupal 6 ne nécessitait aucun correctif, la gestion des correctifs sous Drupal 8 est devenue une tâche à part entière. Dans la plupart des cas, on pouvait compter sur l’appui de la communauté Drupal, même si l’élaboration du projet a été retardée dans certaines régions en raison de la dépendance vis-à-vis de modules externes.