Tutoriel du module Config ignore pour Drupal

Dans le précédent tutoriel, nous avons parlé du module Config Split pour Drupal 8. Aujourd'hui, je vais vous présenter un autre module lié à la configuration pour Drupal 8/9 - Config Ignore. Ces deux modules se chevauchent partiellement. Les deux nous aident à garder les configurations séparées entre les différents environnements. Cependant, l'utilisation est légèrement différente. Il en va de même pour le résultat. La meilleure façon d'apprendre et de comprendre est d'utiliser des exemples concrets.

Supposons que nous ayons besoin de développer la fonctionnalité d'envoi de courrier électronique. Nous pouvons vouloir styliser un modèle. Ou créer un événement pour lequel nous voulons envoyer un message spécifique à l'administrateur du site. Ou créer une notification sur l'exécution d'un cron. Ou simplement s'assurer que nous pouvons envoyer des courriels !

Dans cet exemple, nous utiliserons l'adresse électronique par défaut du site. Dans l'environnement local, nous utiliserons probablement notre propre adresse électronique, n'est-ce pas ? Mais lorsque nous exportons les configurations pour l'environnement de test ou l'environnement réel, nous ne voulons pas que notre email soit défini comme l'email par défaut, mais plutôt que ce soit l'email réel. Nous devons donc ignorer cette configuration. Pouvons-nous faire cela ?

Bien sûr que si ! Vous êtes déjà curieux ? C'est parti !

Nous devons d'abord installer et activer le module Config Ignore :

composer require drupal/config_ignore 
drush en config_ignore 

Vidons également le cache

drush cache:rebuild

et le module serait déjà opérationnel. Il dépend d'un autre module - Config Filter, mais cela est géré automatiquement pour nous. Nous devons juste approuver l'activation des deux modules si nécessaire. Ce module travaille plus près du système de configuration du noyau, il n'est donc pas évident à première vue de savoir où il se situe. Nous n'avons pas de nouvelles entrées dans la zone principale Configuration → Développement. Voyons ce qu'il en est.

Comme mentionné précédemment, rien de spécial. Juste le système de synchronisation de configuration par défaut, fourni par le noyau que nous utilisons habituellement pour importer et exporter nos configurations. Lorsque nous exécutons ces actions via les commandes drush [config:import] et [config:export], nous déclenchons essentiellement les mêmes actions que celles que nous voyons ici. Mais voyons ce qu'il y a à l'intérieur.

OK, ici nous avons déjà un autre onglet à côté des onglets standards. Il s'agit de l'onglet "Ignorer" sur lequel nous devons travailler. Voyons à quoi il ressemble.

C'est assez simple. Il s'agit simplement d'un formulaire dans lequel nous pouvons placer les configurations que nous voulons ignorer. Les personnes qui l'ont créé décrivent même comment l'utiliser. Merci les gars ! Je ne vais pas reproduire les exemples que nous avons là, mais plutôt me concentrer sur notre cas d'utilisation spécifique. Nous avons besoin que notre courrier électronique ne soit utilisé que pour le développement local. Les prochaines choses dont nous aurons besoin sont les suivantes :

• lorsque nous exportons les configurations, notre email ne doit pas être exporté parmi elles
• lorsque nous importons les configurations, nous ne voulons pas que l'email réel de l'environnement de test ou de l'environnement réel soit utilisé à des fins de développement, et nous ne voulons donc pas que notre configuration soit écrasée.

Config Ignore à la rescousse ! Nous avons plusieurs façons de décrire les configurations. Mais tout d'abord, exportons les configurations initiales afin de pouvoir voir la différence par la suite :

drush config:export

Note : Ne procédez pas encore à l'étape suivante. Je le fais ici uniquement pour des raisons d'explication.

Je suis allé dans Configuration → System → Basic site settings, j'ai changé l'email par le mien et j'ai sauvegardé. Maintenant, quand nous retournons à la partie synchronisation de la configuration (Configuration → Développement → Synchronisation de la configuration), nous voyons un changement dans le fichier system.site.yml et nous pouvons le vérifier en cliquant sur Voir les différences.

Ajoutons maintenant la chaîne de configuration de l'image ci-dessous dans l'onglet "Ignorer" et appuyons sur le bouton "Enregistrer la configuration".

Mais maintenant, lorsque nous exporterons à nouveau, nous verrons les deux changements - l'un dans system.site et l'autre dans config_ignore.settings. Et ce n'est pas ce que nous voulons. Nous n'avons besoin que du second. La raison pour laquelle nous voyons les deux maintenant est que le système de configuration ne sait pas encore qu'il doit ignorer celui de system.site. Il serait donc préférable d'ajouter d'abord l'enregistrement dans la zone Ignorer, d'exporter, puis de modifier l'adresse électronique et de sauvegarder. OK, faisons les choses correctement cette fois-ci.

Nous visitons l'onglet Ignorer et ajoutons l'un des éléments suivants :

- system.site → Notez que cela ne tiendrait pas compte de l'ensemble de la page "Paramètres de base du site".

- system.site:mail → Ceci n'ignorerait que la partie email du paramètre. Vous avez remarqué les deux points avant mail ? C'est ainsi que l'on peut ignorer une clé spécifique d'un fichier de configuration. Utilisons-la maintenant. Cette fois, nous devrions avoir ce qui suit :

Nous sommes prêts à exporter via :

drush config:export

afin de s'assurer que l'email sera ignoré la prochaine fois que nous le modifierons. Cette fois-ci, nous ne voyons que le changement dans 'config_ignore.settings'. C'est ce à quoi nous nous attendions. Allons maintenant modifier cet email. Après cela, voyons ce que l'onglet "Synchroniser" nous montre.

Le système est suffisamment intelligent pour voir la différence, mais il l'ignore et nous fait même savoir qu'elle a déjà été ignorée. Maintenant, nous voyons seulement qu'il y a un changement, mais nous n'avons pas le bouton pour le voir. Nous sommes maintenant prêts à modifier la valeur de l'e-mail autant que nous le souhaitons. Il est important de préciser que, puisque nous n'avons ignoré que le courrier, tout autre changement dans system.site serait traité comme un véritable changement par le système, c'est-à-dire qu'il ne serait pas ignoré à moins que nous ne placions l'ensemble de system.site dans la zone Ignorer ou dans l'une de ses clés, de la même manière que nous l'avons fait pour le courrier. Chaque nouvel enregistrement doit être placé sur une nouvelle ligne. C'est ainsi que fonctionne le module Config Ignore.

Je suis sûr que vous l'avez déjà remarqué, mais permettez-moi de le souligner uniquement pour des raisons d'exhaustivité. Cette configuration doit maintenant être mise en place avec sa valeur réelle dans chaque environnement différent, ce qui signifie que vous devrez toujours mettre à jour les messages dans l'environnement de test, l'environnement réel ou tout autre environnement. Elle ne sera pas remplacée par des actions d'importation ou d'exportation.

Cela fonctionnerait avec toutes les configurations, même s'il s'agit d'une configuration personnalisée que nous avons définie nous-mêmes. Il faut juste garder à l'esprit qu'ignorer une nouvelle configuration la laisserait vide, même si elle a une valeur dans l'environnement local. L'exporter cependant générerait le fichier yml afin qu'il soit disponible partout.

Il s'agit d'un bref tutoriel sur l'utilisation du module Config Ignore. Nous pouvons également souligner quelques différences entre ce module et le module Config Split. Ils ont tous deux leurs points forts. Alors, comment choisir lequel utiliser ? Cela dépend du cas d'utilisation que nous avons, mais voyons leurs spécifications :

• Config Ignore - plus simple à utiliser, plus proche de la fonctionnalité de base. Ajouter une autre configuration pour l'ignorer est aussi simple que de la mettre dans le formulaire. Cependant, il faut veiller à ce que la configuration soit la même dans chaque environnement. S'il n'y a que quelques enregistrements ajoutés, ce n'est pas un vrai problème.
• Config Split - plus puissant, il permet de définir à l'avance tous les environnements possibles. Cela nous permet de prédéfinir les configurations que nous voulons pour chaque environnement et de les oublier une fois qu'elles ont été importées. Il existe également une option permettant de configurer un module entier activé ou désactivé par environnement, ce qui est beaucoup plus facile. Cependant, cette option est légèrement plus difficile à mettre en place et à utiliser.

En fin de compte, c'est une question de préférence.

J'espère que ce tutoriel vous sera utile !