La migration du site de BOSSTEK vers Drupal 8.4 : une mise à jour … et un peu plus !
Drupal : Une communauté qui a beaucoup évolué
L’arrivée de Drupal 8 a bousculé beaucoup de principes et méthodes parmi les utilisateurs du CMS. Le framework Symfony et les nombreuses bibliothèques élargissent les possibilités et le nombre de développeurs potentiels. Ces nouveautés introduisent des dépendances. Il faut être plus vigilant que par le passé lors des mises à jour.
Depuis huit ans d’existence, le site de bosstek.fr est témoin des évolutions du CMS. De Drupal 6 à Drupal 7 et maintenant Drupal 8, nous avons vu beaucoup d’améliorations dans l’organisation de la communauté. De plus en plus structurée, la démarche s’est professionnalisée, automatisée et consolidée. Aujourd’hui, en faisant preuve de réactivité et d’organisation, un site construit avec Drupal est robuste et sûr. De la réactivité, il en faut, car la roadmap du CMS est réglée comme du papier à musique … et il faut la suivre !
Beaucoup de sites très importants sont développés avec Drupal. L’effet bénéfique : le nombre de modules reversés et maintenus par des professionnels augmente. Des audits réalisés par les grands comptes améliorent la sécurité de Drupal. Un effet pervers : les développeurs amateurs qui représentaient avant la majorité des contributions, doivent aujourd’hui suivre le rythme cadencé. Les modules doivent respecter les règles de codage et être validés par les tests automatisés. Le site drupal.org fourni une solution d’intégration continue, aux développeurs de fournir le code des tests pour valider leurs modules.
Conséquence de tous ces changements : beaucoup de projets n’ont pas passé le cap de Drupal 8. D’autres projets importants, depuis novembre 2015, ne sont jamais passé en version stable.
Les nouveautés de Drupal 8.4
Les nouveautés apportées par la version 8 de Drupal étaient attendues depuis longtemps par la communauté : édition rapide, fonctionnement "headless", internationalisation, views, wysiwyg, responsive, gestion des champs et modes d’affichage pour toutes les entités (types de nœuds, blocs, utilisateurs, media), import/export de configurations en YAML, etc.
Chez BOSSTEK, nous avons choisi de refondre le site de la société avec Drupal 8 l’été 2016. Depuis, nous avons suivi le rythme et effectué les mises à jours le plus souvent possible. L’été dernier, il s’agissait de passer de versions mineures 8.2 à 8.3. Les défauts de jeunesse de Drupal 8 se sont révélés, apportant leur lot de contraintes et opérations délicates. Nous avons pris différentes mesures temporaires et nous avons attendu la version 8.4 pour faire la migration. Nous parlons de migration car il ne s’agit pas uniquement de mises à jours comme nous le verrons plus loin.
La version 8.4 apporte les nouveautés suivantes :
- Mise à jour majeure de Symfony et jQuery, mises à jour de librairies pouvant compromettre la rétro-compatibilité de certains projets par leurs dépendances.
- Arrêt du support de Internet Explorer 9 et 10.
- Rupture de compatibilité avec Drush < 8.1.15.
- Les modules Datetime Range, Inline Form Errors, Layout Discovery, Media et Workflows, sont désormais considérés comme stables.
- Des évolutions dans les modules expérimentaux du cœur, principalement les modules de la famille Migrate.
- Évolutions de l'interface.
- Améliorations diverses : API REST, API développeurs, performances/scalabilité, tests, administration, authoring, etc (dans la version 8.3 également).
Ces nouveautés ne sont pas sans conséquences, en particulier les mises à jour de Symfony, jQuery et des bibliothèques. Attention de bien surveiller les dépendances de vos modules qu’ils soient communautaires ou faits maison !
La migration : contraintes et petites contrariétés !
Dans le cas de BOSSTEK, 3 modules majeurs ont apporté leur lot de complications.
Une mise à jour du cœur de Drupal est standardisée depuis longtemps : remplacer les fichiers du cœur, conserver les fichiers spécifiques au site, faire un passage sur la page update.php et le tour est joué ! Plus simple encore, utiliser composer et drush pour les plus techniques d’entre nous et si l’environnement le permet.
Dans notre cas, les modules à surveiller étaient Media Entity, YAML Form et Layout plugin. Media Entity a été intégré dans le cœur de sous le nom Media. Ce dernier n’est pas visible par défaut. Il est nécessaire d’utiliser Drush ou activer un module dont Media fait parti des dépendances pour qu’il se révèle dans l’interface. Le manque de stabilité général de l’écosystème Media avec la solution "in core" nous a incité à conserver la solution de Media Entity en tant que module communautaire. C’est d’ailleurs la recommandation jusqu’à la sortie de Drupal 8.5 prévue en mars 2018.
Là où nous avons pu mesurer l’effervescence autour de la sortie de Drupal 8 il y a deux ans, en positif comme en négatif, c’est avec les modules YAML Form et Layout plugin. Chacun à leur façon, révèlent aujourd’hui des défauts de jeunesse.
Le module YAML Form nous a instantanément plu lors de la sortie de Drupal 8. Il était très complet et pratiquement le seul viable face aux autres modules, en particulier Webform qui ne semblait pas arriver à passer le cap de Drupal 8. Deux ans plus tard, Webform reprends finalement la main et YAML Form est arrêté. Les utilisateurs sont incités à migrer vers Webform. Le problème : la migration passe par un script type "chercher et remplacer". Hasardeux pensez-vous ? C’est ce que nous avons pensé. Par curiosité, nous avons réalisé un essai malgré tout. La méthode n’ayant pas fonctionné dans notre cas, nous avons usé d’une autre stratégie. Finalement, nous avons profité d’une nouvelle fonctionnalité très appréciable dans Drupal 8 : l’import / export de configurations en YAML. Ainsi, les formulaires ont été recréés très rapidement, évitant le risque d’oubli ou de fausse manœuvre de la méthode "chercher et remplacer".
Concernant Layout plugin, le module a été intégré dans le cœur de Drupal. L’activation implique un ensemble de prérequis et un mode opératoire précis. Tout comme Media Entity, en intégrant le cœur de Drupal, il change de nom pour : Layout Discovery. Il s’agit surtout d’un module de service qui permet à d’autres modules de déclarer des mises en page. Les modules dépendants doivent également prendre en compte cette migration. C’est là que les choses se compliquent : il faut que la mise à jour des modules ait lieu dans la même opération que l’activation de Layout Discovery et la désactivation de Layout plugin. Là encore, les solutions proposées par les différents contributeurs n’ont pas été concluantes dans notre cas. La solution d’import / export de configuration YAML est possible. Cependant, elle implique l’export de nombreuses configurations à titre de dépendance. Nous avons préféré suivre la méthode proposée dans notre mode opératoire ci-après.
Pour les utilisateurs du thème "business", après migration, le diaporama ne s’affiche plus. La mise à jour de jQuery qui accompagne la version 8.4 de Drupal avait rendu obsolète le petit morceau de code JavaScript qui lance le diaporama.
La migration : notre mode opératoire
Afin de maîtriser un maximum de risques, avant toute opération, nous nous assurons de travailler dans un environnement identique à la machine de production. Nous effectuons un dump de la base de donnée et une sauvegarde des fichiers du site. Dépendant de votre niveau d’accès et d’expérience, un module toujours très pratique pour faire des sauvegardes par l’interface est à recommander : Backup and Migrate.
Finalement, 3 opérations délicates doivent être maîtrisées pour cette migration : la mise à jour de Drupal 8.2 vers 8.4 (ainsi que des modules et librairies personnalisées), la migration de Layout plugin (avec ses dépendances) et la migration de YAML Form vers Webform.
Nous avons commencé par lister les dépendances de Layout plugin et repérer leurs paramètres dans la configuration de notre site. Que ce soit par export de configuration ou simples notes, il faudra rejouer ou importer ces paramètres après la mise à jour du cœur. Dans notre cas, il a fallu enregistrer les paramètres de Display Suite (ses sous-modules inclus), de Bootstrap Layouts et les modes d’affichage de nos types de contenu. Nous avons également repéré plusieurs points de contrôle qui seront les témoins d’une migration réussie après coup.
L’étape suivante est la désactivation de Display Suite (sous-modules inclus), de Bootstrap Layouts et de Layout plugin.
À partir de là, le mode opératoire est le suivant : passer en mode maintenance et faire un dump de la BDD comme dans une mise à jour classique. Remplacer tous les fichiers et dossiers nécessaires à la mise à jour du cœur, des modules et des librairies éventuelles.
Visiter la page update.php et suivre le processus. Une fois l’opération terminée, visiter la page des modules. Dans l’interface de Drupal 8, il s’agit de l’onglet "extend" ("extension" en version française), ré-activer les modules précédemment désactivés à l’exception de Layout plugin. À la place activer le nouveau module du cœur : Layout Discovery.
Importer ou rejouer les configuration des modules, types de contenu et modes d’affichage liés. Enfin, vérifier la conformité du site grâce aux points de contrôle précédemment repérés. Il est possible que les aspects cosmétiques du site aient changé. Dépendant de la façon dont les feuilles de styles ont été travaillées, les classes CSS utilisées peuvent avoir changé de nom.
Il en va de même pour la migration de YAML Form. Si l’étape précédente de mise à jour du cœur des modules et de Layout plugin est un succès, effectuer une nouvelle sauvegarde. Exporter la configuration des différents formulaires, désactiver YAML Form et activer Webform. Importer les formulaires et vérifier les paramètres. Attention aux URL afin de maintenir le référencement précédemment acquis pour ces pages. Les CSS auront là aussi besoin de travail selon les cas.
Astuces
Profitant de cette opération sur notre site internet, nous avons fait évoluer certaines fonctionnalités. L’occasion pour nous de partager deux astuces.
Le thème Business utilise les diaporama Flexslider qui, dans certains cas peut se montrer récalcitrant dans la gestion des images de fond des diapos. L’enregistrement des images, en lien avec le problème qu’a Drupal à gérer les images dans certains cas peut résulter en écran blanc lors du passage du cron. Seules les images présentes par défaut dans le dossier images du thème ont tendance à être affichées sans bug afférant. Les paramètres du thème permettent de modifier le nombre de diapos (3 par défaut). Nous l’avons modifié pour avoir 5 diapos. Problème : seules les 3 premières images s’affichent. Notre solution : faire un export de configuration YAML, la personnaliser, puis l’importer avec les nouveaux paramètres. Résultat : les images s’affichent correctement.
Node in Block, un module que nous apprécions beaucoup dans Drupal 7, permettait d’afficher des nœuds dans des blocs. Très pratique pour afficher des contenus facilement dans n’importe quelle zone du thème. Celui-ci n’est plus disponible pour Drupal 8. À première vue cela peut sembler surprenant, mais ça ne l’est pas du tout. Les nouvelles possibilités offertes par Drupal 8, en particulier le fait de pouvoir créer des types de blocs personnalisés, répond déjà à ce besoin. En effet, les blocs sont maintenant des entités à part entières. Entièrement personnalisables, avec un système de champs et des modes d’affichage, ces nouveaux blocs ouvrent beaucoup de possibilités. À savoir également : un bloc peut être placé dans différentes zones. Il se comporte alors comme autant de copies que d’emplacements différents, autorisant une personnalisation encore plus poussée. Afin de reproduire la fonctionnalité de Node in Block, nous aurions pu utiliser une vue puisque le module Views est désormais intégré au cœur de Drupal. Cependant, cela représente une solution lourde et peu ergonomique. Finalement, afin de reproduire la fonctionnalité, il nous a suffit de créer un nouveau type de bloc dont l’unique champ est de type "référence à un contenu". Le tour est joué ! Nous pouvons même définir le type et le mode d’affichage du contenu référencé par ce bloc : par exemple un article en mode teaser.
Conclusions
Drupal 8 avance à un rythme soutenu et régulier. Il faut être capable de suivre ce rythme si l’on souhaite garantir l’intégrité et la sécurité d’un site internet. Après deux ans d’existence, plusieurs modules majeurs n’ont pas encore rattrapé le calendrier de livraison. Un exemple : voting API dont plusieurs modules dépendent, n’est pas en cette fin d’année 2017 en version stable. Nous pourrions aussi citer Webform, Captcha, Backup and Migrate, XML sitemap, Field collection, etc.
Heureusement, Drupal 8 offre par défaut de plus en plus de fonctionnalités. Là où par le passé, il n’était pratiquement pas possible de construire un site sans modules additionnels, aujourd’hui c’est possible. Parmi les nouvelles fonctionnalités, l’interface d’import / export de configurations YAML est un plus indéniable que nous nous devons de saluer.
La mutation de Drupal avec la version 8 transforme le système de gestion de contenu ("CMS") en plateforme de gestionnaire de contenu ("CMF") par intégration du framework Symfony. Cela rend la vie dure à certains projets alors que d’autres s’épanouissent grâce à cette nouvelle ouverture. Plus que jamais, Drupal est un outil professionnel destiné à une grande diversité de projets des plus petits aux plus ambitieux. Néanmoins, l’accès pour les novices est de plus en plus facilité par l’intégration de modules packagés avec le cœur. Livrés en standard, ils permettent "out of the box" de construire rapidement des sites standardisés, performants et conformes aux exigences actuelles d’ergonomie et de sécurité.
Il ne faut cependant pas oublier qu’un site si simple qu’il soit, a un coût ! L’animation, la modération, la maintenance, les sauvegardes, autant de tâches qui nécessitent un investissement permanent et un minimum de compétences. Il arrive que la communauté prenne des décisions qui impliquent un travail supplémentaire de maintenance imprévu. C’est là que l’expérience fait la différence et participe à la consolidation d’une vraie expertise.