Drupal est l’association entre un ensemble de fichiers et une base de données. Comme tout CMS la construction du site est principalement faite via le back-office et les différents paramètres sont enregistrés dans la base. Lorsque l’on souhaite déployer son site, il faut donc transférer à la fois des fichiers et des données contenues dans la base.

Historiquement Drupal ne proposait pas de système d’import/export du paramétrages des modules avant la version 8. On utilisait alors le module Features (https://drupal.org.project/features) qui permet de packager des fonctionnalités sous forme de module et donc de déployer ces dernières.

Tout a changé avec l’arrivée de Drupal 8, qui propose nativement une gestion (import/export) de toute la configuration stockée en base. 

Système de configuration

Le système de configuration a été développé dans le but de pouvoir déployer un même site sur différents environnements (par exemple un environnement de recette, pré-production, production, etc…). Toute la configuration est stockée en base de données. Elle est mise à jour via les formulaires du back-office. Tout module ou thème peut ainsi proposer ses propres objets de configuration sous forme de fichiers. Ces derniers sont automatiquement chargés en base de données lors de leur installation.

Il est possible ensuite de synchroniser la configuration entre la base de données et les fichiers.

Lors d’un import ou d’un export, Drupal va possiblement mettre à jour, créer ou supprimer des configurations. Par exemple lors d’un import depuis les fichiers vers la base de données, si une configuration existe en base mais pas dans les fichiers, alors Drupal va la supprimer de la base. A l’inverse si une configuration n’existe que dans les fichiers, alors Drupal va la créer en base lors de l’import.

La documentation officielle est disponible sur https://www.drupal.org/docs/8/configuration-management/managing-your-sites-configuration.

Limitations de la gestion de la configuration

Drupal 8 permet donc de déployer toute la configuration entre les différents environnements, mais il est pour le moment difficile d’avoir des configurations propres à un environnement. Cela pose certains problèmes, car en pratique on ne souhaite pas forcément déployer toute la configuration.

Lorsque l’on développe localement un site, on utilise certains modules qui ne doivent pas être installés sur les autres environnement. C’est le cas du module Devel (https://www.drupal.org/project/devel) par exemple. Mais d’autres modules sont concernés également (Kint, WebProfilerViews UI, Field UI, Stage File Proxy (https://www.drupal.org/project/stage_file_proxy), etc…). Afin d'exclure ces modules et leurs configurations lors d'un export, on peut utiliser un fichier de settings (par exemple le fichier /web/sites/default/settings.local.php) et définir la liste de ces modules. Cela n'est possible que depuis la version 8.8 de Drupal et en utilisant Drush en version 10 uniquement.

On peut aussi avoir besoin de configurer différemment un module suivant les environnements, afin par exemple d’avoir des clés d’API de tests et de production différentes. Or lorsque Drupal exporte les configurations locales, il exporte toutes les configurations de tous les modules installés. On risque donc de se retrouver avec du paramétrage de développement qui va être déployé sur tous les autres environnements.

A l’inverse il est possible d’avoir besoin d’installer des modules uniquement sur l’environnement de production.

On a également certains modules dont la configuration est modifiée directement sur la production, par exemple l’email du site qui peut légitimement nécessiter d’être mis à jour. Ainsi on risque au prochain déploiement d’écraser sa valeur lors de l’import des configurations. Il est donc important d’avoir un mécanisme permettant de protéger certaines configurations en production.

Il est possible que certains modules créent des nouvelles configurations sur l’environnement de production. L’exemple le plus commun est le module Webform (https://www.drupal.org/project/webform). Chaque nouveau formulaire ajouté crée un objet de configuration. Ainsi les configurations de formulaires ne sont présentent que sur la production et seront supprimées au prochain import. Il nous faut donc pouvoir protéger ce type de configuration lors des déploiements.

Actuellement Drupal ne propose pas d’imports/exports sélectifs. On utilise donc des modules comme Config Split (https://www.drupal.org/project/config_split). De nombreux autres modules peuvent se révéler utiles suivant les cas pratiques. Citons par exemples : 

Notons également le module Environment Indicator (https://www.drupal.org/project/environment_indicator) qui permet de mieux identifier visuellement les différents environnements en modifiant la couleur de la toolbar.

Tout est-il configuration ?

La plupart des modules souhaitant proposer des paramètres utilisent le système de configuration. Cependant certains paramétrages sont propres à un environnement, comme par exemple les clés d’API qui peuvent être différentes entre les environnements de tests et de production.

Tout le paramétrage dans le back-office n’est pas forcément de la configuration. On peut avoir des options différentes entre les environnements.

State API

La State API permet de stocker en base n’importe quel type de données. On l’utilise pour enregistrer des données propres à l’état du site dans un environnement particulier. L’un des exemples du coeur de Drupal est le timestamp correspondant à l’heure du lancement des tâches planifiées. Cette donnée n’est ni du contenu, ni de la configuration et n’est jamais déployée.

La State API est ainsi très pratique pour proposer des paramètres du site qui sont enregistrés en base sans qu’ils fassent parti de la configuration. On pourrait l’utiliser, par exemple, pour stocker des clés d’API. Notons que le mode maintenance que l’on peut activer via le back-office est stocké avec State API.

Surcharge de la configuration

La configuration active est stockée en base par défaut. Il est cependant possible de la surcharger via des fichiers de settings ou bien via des modules (config.factory.override tagged services). Ainsi la valeur utilisée effectivement est définie « en dur » et ne peut pas être modifiée via le back-office de Drupal.

Cela est très pratique pour redéfinir des valeurs de configuration pour chaque environnement. Mais attention ces valeurs n’apparaissent pas dans les formulaires de configuration. En effet lors du chargement d’un formulaire de configuration toutes les valeurs sont chargées depuis la base. On a aucune indication d’éventuelles surcharges. Cela est particulièrement problématique et des modules existent comme Configuration Override Warn (https://www.drupal.org/project/config_override_warn) pour palier ce problème.

Ce système de surcharge peut donc être très pratique pour redéfinir certains paramètres, mais on ne peut pas les éditer facilement. Il est nécessaire de modifier des fichiers sur le serveur et donc d’avoir les droits suffisants.

Manipulation de la configuration

On constate donc que le système de configuration intégré actuellement au coeur de Drupal 8 n’est pas suffisante et qu’il est nécessaire d’utiliser des modules contrib supplémentaires. Cela change avec les versions mineures du coeur qui petit à petit intègrent des fonctionnalités plus avancées en terme de gestion des import/export entre les différentes instances d’un même site. Plus de détails sont disponible sur https://www.drupal.org/project/drupal/issues/3033427. L’idée générale est de pouvoir intervenir sur la configuration lors des imports/exports, afin d’exclure et/ou modifier certaines configurations. Les modules souhaitant manipuler la configuration lors des synchronisations pourront utiliser la ConfigTransform API.

Au final...

Drupal 8 est une avancée conséquente en matière de déploiement par rapport aux versions précédentes, mais il y a toujours certaines limitations qui peuvent poser problèmes. Des modules contrib existent pour palier ces dernières, et comme la communauté Drupal est toujours réactive le coeur de Drupal évolue aussi avec les différents besoins qui apparaissent. 

Dans la même catégorie

CMS Drupal

Drupal : LE CMS pour les professionnels ?


Drupal et les structures de données

Que reste-t-il à Drupal ?


Drupal et les structures de données

Drupal et les structures de données