Après avoir découvert le principe des profils d'installation, leur création, et la conception de packages fonctionnels, nous allons aborder dans ce billet un cas d'application typique des profils d'installation : la création d'une usine à sites, basée sur l'architecture multi-sites native à Drupal, ou comment industrialiser la conception d'un projet pour disposer d'un site fonctionnel en quelques minutes, sans pour autant sacrifier la notion du sur-mesure.
Après une définition préalable des besoins, des cas d'usage souhaités (un site One Page, un site collaboratif, un site événementiel, un site de valorisation, une simple vitrine, etc., le tout multilingue ou non), les différents packages fonctionnels nécessaires à tel ou tel type d'usage pourront être réalisés, en distinguant dans la mesure du possible d'une part les packages dit de bas niveau (i.e. réutilisables partout, quelque soit le type de site à générer, comme par exemple les styles d'image ou des types de paragraphs) et d'autres part les packages qu'on pourrait appeler métier, regroupés par type de fonctionnalité.
Cette approche peut alors nous permettre de pouvoir mixer relativement aisément différents cas d'usage lors de la génération d'un site, que nous pourrons regrouper par type de site et intégrer dans notre profil d'installation.
Un des enjeux majeurs d'une telle solution n'est pas tant la génération de sites web que leur maintenance sur le moyen/long terme. Comment maintenir des dizaines, des centaines de sites propulsés par une architecture multi-sites, sans que cela devienne ou bien un casse-tête ou bien une usine à gaz ? Là encore Drupal 8 nous offre plusieurs solutions, bien plus robustes qu'auparavant, grâce à la nouvelle gestion de sa configuration.
Redonner le pouvoir aux modules
Par défaut, Drupal considère qu'une fois une configuration importée (depuis un module), c'est alors le site qui est responsable de sa configuration. Aussi pour modifier la configuration de dizaines de sites, nous devrions normalement l'appliquer séparément sur chacun des sites. Pas très enthousiasmant non ?
Pour maîtriser la configuration de sites générés par un profil d'installation, au sens pouvoir la maintenir, la faire évoluer, la sécuriser, il nous suffit de redonner aux modules le pouvoir de modifier et de mettre à jour leur propre configuration. Et comme notre profil d'installation n'est au final qu'une composition de modules apportant chacun un jeu de configuration bien précis, nous aurons alors la possibilité de modifier la configuration de l'ensemble des sites générés par notre profil d'installation, en ne modifiant qu'un seul fichier.
Pour redonner le pouvoir aux modules sur leurs configurations, nous allons utiliser le module Configuration Synchronizer, et du patch suivant #2445463 qui apporte le support de Drush pour ce module. Ce module va nous permettre de faire un snapshot de la configuration importée, de la comparer à la configuration active d'un site, et de modifier cette configuration depuis les modules ou les thèmes, et ceci en veillant à ne pas supprimer des modifications qui auraient été faites sur le site suite à l'installation des modules.
Démonstration
Nous vérifions ici la configuration de nos sites propulsés par l'usine à sites.
Modifions par exemple une configuration depuis le code source du profil d'installation.
Ici nous modifions le titre de la vue Publications, fournie par le module uas_publication.
Puis nous vérifions à nouveau l'état de la configuration de nos différents sites.
Et nous pouvons alors mettre à jour la configuration de tous nos sites grâce à une commande, en quelques secondes.
drush cs-update [nom_module] -y
Cette commande nous permet de mettre à jour la configuration d'un site à partir des modules, à condition que cette configuration n'ait pas été modifiée depuis l'interface. Si nous souhaitons malgré tout écraser les modifications effectuées sur le site, il nous suffit alors de rajouter l'option --unsafe à notre commande.
drush cs-update [nom_module] --unsafe -y
Enfin, Configuration Synchronizer devrait s'enrichir prochainement de la possibilité de fusionner des modifications de configuration qui auraient été effectuées à la fois depuis le site lui-même et mises à jour depuis les fichiers de configuration du module.
Couplée au module Configuration read-only mode, qui interdit toute modification de configuration d'un site Drupal 8 depuis l'interface (dans le but d'imposer un processus de mise à jour depuis un environnement de pré-production par exemple), cette solution est d'une redoutable efficacité pour maîtriser dans la durée toute une galaxie de sites propulsés par une usines à sites.
Enfin, je ne peux pas conclure cette série de billets sur les profils d'installation et la gestion de la configuration, sans évoquer le poids lourd Features qui va retrouver tout son sens sur Drupal 8, à savoir la création et le packaging de fonctionnalités. En phase bêta actuellement, Features devrait couvrir le périmètre fonctionnel (export et import, mais aussi visualisation des différences entre la configuration du module et la configuration active) de Configuration development et Configuration synchronizer, en plus d'apporter une UI pour gérer tout cela (ces 3 modules sont basés sur le même socle, fourni par le module Configuration Update Manager).
Grâce à l'API de configuration de Drupal 8, et sa promesse tenue de fournir au coeur ou aux modules contribués une consistance quant à la gestion de la configuration, il faut souligner que tout module créé et packagé avec le module configuration Development peut être transformé en une Feature en ajoutant simplement le fichier [nom_module].features.yml (avec comme contenu la valeur true) à la racine du module.
Envie d'en savoir plus sur les usines à sites ? Vous avez le projet d'industrialiser la production de vos sites ? N'hésitez pas à contacter un freelance spécialiste Drupal 8 pour en discuter. Et ce d'autant plus que les architectures possibles évoluent avec une nouvelle solution d'industrialisation basée sur le module micro site permettant de mettre en place une Usine à site Drupal 8 très rapidement avec une maintenance extrêmement facilitée.
Billet mis à jour le 16 décembre 2018
Commentaires
Aegir ?
Avec Drupal 8 et le gestionnaire de configuration, est-il toujours pertinent d'utiliser Aegir, pour le moment vieillissant avec Drush 8 (malgré le développement actuel de Aegir 4), ou d'utiliser la succession d'outils Drush 9, composer, features + configuration API ?
Ajouter un commentaire