Drupal 10 : Gestion de la configuration

Philosophie

L’industrialisation est un sujet récurrent depuis pas mal d’années dans le monde Drupal. Drupal 7 a été une vraie avancée de ce côté là grâce à Features qui rend bien des choses exportables. Le principal problème c’est que Features n’a pas du tout été prévu pour cela. L’usage premier de Features consiste à assembler un groupe de composants pour en faire une fonctionnalité. Pour une galerie d’images par exemple, on a besoin d’un type de contenu avec quelques champs, d’une vue et d’une librairie. Chaque module contribué a la responsabilité de s’intégrer du mieux possible avec Features pour que ses composants soient exportables.

L’état de l’art est correct, on arrive à exporter la plupart des éléments d’un site mais on sent que c’est parfois laborieux d’exporter certains composants qui sont pourtant des éléments centraux de Drupal (blocs, menus, etc). La principale solution pour remédier à ce problème est d’avoir un système prévu pour cela depuis le cœur, permettant d’enlever une grosse couche de bidouille.

C’est en concertation avec les auteurs de Features que Greg Dunlap, le responsable de l’initiative CMI s’est nourri de leurs retours et des échanges avec la communauté pour concevoir un système et une API dédiés à la configuration dans Drupal.

Nous l’avons abordé dans le chapitre sur l’API de configuration des données, le format d’export des données est le YAML. Chaque type d’entité de configuration définit son format d’export.

Au lieu de gérer des groupes de composants comme vous pouviez gérer vos modules Features, la configuration de votre site est un tout que vous faites évoluer.

Fonctionnement

Pour comprendre comment fonctionne la configuration et comment la synchroniser entre plusieurs environnements, appuyons-nous sur l’illustration suivante :

Icônes par Maria Leandro & Anshul Dhiman - CC 3.0 BY

Pour chaque environnement, vous retrouvez un dossier /sites/default/files/config_<hash_de_sécurité>/sync qui, juste après l’installation de Drupal, est vide.

(1) À chaque fois que vous modifiez de la configuration sur votre site (exemple : vous configurez une vue ou la position de vos blocs), Drupal sauvegarde automatiquement vos changements dans la table config.

(2) Vous voulez envoyer vos modifications sur le serveur de production. Il faut exporter la configuration. Pour cela cliquez sur Configuration > Configuration management > Full import/export > Export et cliquez sur le bouton “Export”. Vous vous retrouverez avec une archive contenant tous les fichiers de configuration de votre site.
L’autre possibilité est d’exporter la configuration par Drush avec la commande :

$ drush config-export sync
# Exporte la configuration vers sync.

Ce qui est intéressant (et même recommandé), c’est qu’il est possible d’indiquer où se situe le dossier sync. Vous pouvez ainsi vous affranchir du hash de sécurité pour mettre les dossiers hors de la racine du site et en profiter pour versionner les fichiers de configuration.

Pour faire cela, voilà la variable à surcharger dans votre fichier settings.php.

$config_directories['sync'] = '../config_hc/sync';

(3) Il faut ensuite rapatrier les fichier sur le serveur de production. Soit via votre gestionnaire de source préféré, soit en rapatriant une archive, l’objectif étant de remplacer les fichiers existants sur le serveur.

(4) Pour que les nouvelles modifications soient prises en compte il faut importer la nouvelle configuration. Soit par l’interface de Drupal dans le menu Configuration > Configuration management > Synchronize, soit par la commande Drush :

$ drush config-import sync --preview=diff
# Importe la configuration depuis sync.

Drupal étant capable de vous indiquer quelles sont les surcharges de configuration à importer vous pourrez contrôler les changements. Une fois fait, le tour est joué, la nouvelle configuration est déployée, votre site prend en compte les changements.

Informations supplémentaires

Il est possible de récupérer ou d’importer un seul fichier de configuration à la fois si on le souhaite via l’interface web ou via la commande Drush :

$ drush config-get <nom_composant> // Récupération.
$ drush config-set <nom_composant> <valeur> // Mise à jour.

Ce qui est intéressant, maintenant que les données sont exportées proprement, c’est que les composants indiquent des dépendances entre eux. Par exemple si vous souhaitez supprimer un champ, Drupal va vous indiquer que la configuration du View mode se servant de ce champ va être supprimée, que la vue dans laquelle ce champ est utilisé va être supprimée. C’est assez sain pour se rendre compte de ce que l’on fait.

Comme vu précédemment, un module peut livrer de la configuration par défaut en la fournissant dans son dossier /config/install. Là où les choses se compliquent un peu c’est que tout n’est pas permis.
Si vous livrez de la configuration “nouvelle”, c’est à dire basée sur votre propre format ou qui n’est pas encore livrée par le cœur de Drupal, dans ce cas la nouvelle configuration sera prise en compte.
En revanche, si vous tentez d’activer un module livrant de la configuration et qui a comme nom machine une configuration déjà livrée par le cœur, vous rencontrerez une erreur.

Exemple : votre module comporte un fichier /config/install/monprojet.config.yml. Ce fichier est importé avec succès.
Si vous avez un fichier /config/install/system.site.yml, là, vous avez une erreur.

La solution consiste alors à faire les actions de surcharge dans votre profil d’installation ou au sein d’un hook_update_N() avec les fonctions de l’API de config. L’alternative consiste à livrer la configuration depuis le dossier config/install de votre profil d’installation. Dans ce contexte précis, votre configuration sera prise en compte sans générer d’erreur.

Il n’est pas possible d’installer un site à partir de sa configuration exportée, vous devez nécessairement installer le site puis importer la configuration. La situation restera en l’état au minimum jusqu’à la version 8.1.x pour plusieurs raisons, consultez l’issue sur drupal.org si vous souhaitez plus de détails [Issue #1613424]. Notez cependant qu’Alex Pott a démarré le module “Configuration Installer” pour faire une installation depuis de la configuration.

Maintenant que le système de gestion de la configuration considère la configuration de votre site comme un tout, si vous vous retrouvez à avoir des modifications introduites sur votre site en production vous risquez d’avoir un problème.
Si vous souhaitez interdire à votre client de faire la moindre modification en production vous pouvez utiliser le module “Configuration Read-only mode” qui vous protégera.
Cela étant dit, les modifications en production peuvent être légitimes, il arrive que des équipes laissent la main à leur client pour repositionner des blocs ou modifier la structure d’une page.

Dans un tel cas de figure, vous allez devoir faire face à un problème lorsque vous allez vouloir déployer les nouveaux changements réalisés par les développeurs.
L’API du cœur ne sait faire que deux choses : importer la nouvelle configuration définie ou exporter la configuration actuelle du site. Dans le premier cas vous perdriez les modifications faites sur le site, dans le second les nouveaux changements seraient écrasés.
Pour remédier à cela, les gens de Pantheon ont développé le module drush config-extra qui expose quelques nouvelles commandes. Celle qui nous intéresse est config-merge, elle va exporter les nouveaux changements dans le dossier “staging” en même temps que fusionner les nouveaux changements de l’équipe. Idéal pour que tout le monde reste content, il se peut même que cela vous serve pour la synchronisation entre développeurs.

La commande config-merge s’utilise comme suit :

$ drush @dev-site config-merge @production-site

L’autre solution qui s’offre à vous consiste à rapatrier une copie de la base de données de la production en local avant de commencer vos nouveaux développements, exporter cette nouvelle configuration et la versionner puis construire votre nouvelle fonctionnalité à partir de cet existant.