Les configurations Drupal

Drupal est un CMS (système de gestion de contenu en français) libre et open source. Drupal est un outil qui s’adresse à la fois à des débutants ou des programmeurs experts. Sa flexibilité lui permet de répondre à la très grande majorité des besoins du marché : sites institutionnels, blog, annuaire, communautaire, marchand ou intranets, tout est possible.

Dans cet article, je vous ferai un rapide rappel des notions de base, puis nous parlerons plus technique...

Notions de base

Par opposition au contenu du site, la configuration est l’ensemble des paramètres d’administration qui déterminent son fonctionnement. La configuration comprend généralement des éléments tels que le nom du site, les types et les champs de contenu, les vocabulaires de taxonomie, champs de vues...

Il n’est pas recommandé de modifier la configuration d’un site directement en production. Le système est conçu pour faciliter le test des modifications en local, leur exportation vers des fichiers et leur déploiement en production. La configuration est stockée dans l’arborescence du projet et intégrée au contrôle de version (GIT).

Par défaut, la configuration « active » est stockée dans la base de données (table « config »). Ceci pour des raison de performance et de sécurité. Il s’agit de la configuration complète pour l’ensemble du site à un instant T.

La configuration peut être exportée et importée sous forme de fichiers YAML, soit dans son intégralité, soit sous forme d’un seul élément de configuration, à l’aide des commandes Drush, Drupal Console ou de gestionnaire de configuration (UI dans le BO : admin/config/development/configuration).

L’exportation et l’importation de modifications de configuration entre une installation Drupal dans différents environnements (instances), tels que la dev, la preprod et la production, vous permet d’effectuer et de vérifier vos modifications à une distance confortable de l’environnement réel (prod) de votre site. Cela vous permet de déployer une configuration d’un environnement à un autre (par précaution, Drupal vérifie que le site est le même avant de l’importer, en comparant son UUID).

Workflow

Pour passer des modifications d’une instance à une autre, on se sert de deux commandes principales :

• « drush cex » => alias de « config :export » pour exporter la configuration courante dans les fichiers YAML ;
• « drush cim » => alias de « config :import » pour importer la configuration stockée dans les fichiers YAML vers la base de données… et donc faire en faire la nouvelle configuration active.

Emplacement des configurations

Par défaut les YAML sont stockés dans le dossier « files » du site. Ce qui est peu pratique pour les versionner et les rendent potentiellement accessible depuis internet.

Il est donc vraiment nécessaire de changer cet emplacement. Je vous conseillerais de le placer en dehors du webroot mais toujours dans l’arborescence du projet pour le versionner.

Cela se fait dans le fichier settings.php du site :

$settings['config_sync_directory']='../config/sync';

Exclure des configurations du workflow

Plusieurs situations nécessitent d’exclure des configurations du workflow :

• Modules de développement (devel, watchdog, etc.) ;
• Configurations non applicable ailleurs que sur la production (système de connexion basée sur l’AD d’un client, url d’un webservice, etc.) ;
• Configurations de webforms pouvant être ajoutés par le client.

Il existe plusieurs moyens de gérer ces exclusions.

> Si on veut exclure entièrement un module, Drupal fournit nativement un moyen via le settings.php. Le setting « config_exclude_modules » permet de lister les modules à exclure. Par exemple :

$settings['config_exclude_modules']=['devel','devel_generate','dblog','stage_file_proxy','kint'];

Les modules listés et toute la configuration qui en dépend seront supprimés de la configuration exportée lorsque celle-ci sera exportée. De cette façon, la configuration importée sur le site de production rendra ces modules désinstallés. Cependant, lors de l’importation de la configuration sur l’environnement de développement où le module est déjà installé et où les paramètres sont réglés de manière à exclure le module de la synchronisation de la configuration, le module restera installé et sa configuration restera intacte.

> Si la configuration dans le répertoire de synchronisation contient un « module exclu », celui-ci sera importé et activé comme toute autre configuration ou module. Mais lors de l’export de la configuration, il sera supprimé.
Attention, je vous précise que cette méthode ne fonctionne qu’avec Drush 10+.

Pour exclure des configurations plus ciblées, il existe plusieurs modules contrib. Je vais vous en présenter deux :

• Config Split - Séparer la configuration dans différents dossiers. Ce module permet de faire de nombreuses choses, mais sa configuration reste difficile.^[01]
• Config Ignore - Comme un .gitignore, ce module permet d’ignorer des configurations ciblées, avec la possibilité d’utiliser des wilcards. Ce module est recommandé dans 95% des cas car il est très simple à mettre en place.^[02]

La State API

La State API^[03] fonctionne comme la configuration mais elle est utilisée pour les configurations spécifiques à un environnement comme : l’url d’un webservice ou le timestamp de la dernière exécution d’une tache cron.

Contrairement à la configuration, la State API n’est pas exportée dans des fichiers YAML et ne peut donc pas voyager d’une instance à une autre.

Avec la State API, nous allons uniquement interagir de manière pragmatique. Et si le contexte le permet, il est conseillé d’injecter le service contrairement à l’exemple ci-dessous.

Exemple d’utilisation – Dans le submit d’un formulaire, nous allons enregister dans le State l’url et la clef d’API d’un webservice. Ces valeurs sont spécifiques à l’instance car le webservice à plusieurs instances (sandbox et production).

public function submitForm(array &$form, FormStateInterface $form_state)
  {
    // Récupère la classe d'état => toujours préférer l'injection de dépendance.
    $state = \Drupal::state();

    $state->set('mon_module.webservice_url', $form_state->getValue('webservice_url'));
    $state->set('mon_module.webservice_key', $form_state->getValue('webservice_key'));
  }

Nous allons ensuite pouvoir, très simplement, récupérer ces valeurs dans notre code à d’autres endroits, comme ceci :

$apiUrl = $state->get('mon_module.webservice_url');
$apiKey = $state->get('mon_module.webservice_key');

J’espère que cet article vous a été utile. Je vous conseille de lire également les articles suivants :

• Le cache Drupal : pour une meilleure gestion des performances !
• Carnets de Développeur : pourquoi je ne reviendrai plus sur WordPress après avoir essayé Drupal ?

En savoir plus :

• 01 - Config Split
• 02 - Config Ignore
• 03 - State API

Crédit photo : scanrail