Configuration d’une boutique Magento à partir de la version 2.2

Depuis la version 2.2 de Magento, le système de configuration des boutiques a quelque peu été modifié.

Si les grandes lignes sont toujours présentes, des ajustements ont été apportés afin de simplifier la configuration des boutiques, faciliter le travail collaboratif et le déploiement sur de multiples environnements.

Configuration avant Magento 2.2

Dans les versions inférieures à la 2.2, les valeurs de configuration étaient stockées à 4 endroits différents :

  • La configuration admin globale : app/etc/local.xml
  • La définition des modules : app/etc/modules/...
  • La configuration interne des modules : app/code/.../.../.../etc/config.xml
  • La configuration dans la base de données et dans la table core_config_data.

Il faut noter que si une clé de configuration est définie à deux endroits, c'est la dernière valeur dans l'ordre cité plus haut qui sera prise en compte.

Par exemple, si une valeur est définie dans la configuration interne d'un module, elle pourra être modifiée par une réécriture de la clé dans la table core_config_data.

Les clés sont enregistrées à l’aide de 3 paramètres principaux : une clé texte sous la forme section/group/field, la portée boutique (store ID) et sa valeur.

Configuration à partir de Magento 2.2

Nouveautés

Magento 2.2 introduit une nouvelle commande de son CLI : app:config:dump.

Cette commande est destinée à l'écriture des fichiers de configuration à partir de toutes les sources existantes, y compris la base de données.

Les données vont être exportées dans 2 fichiers et porteront le contenu suivant :

  • app/etc/env.php
    • données sensibles (mots de passe hashés, données de connexion à la base de données, clés API, etc ...)
    • spécifiques à l'environnement courant
  • app/etc/config.php
    • toutes les autres données (base de données, configuration modules)
    • communes à tous les environnements du projet

Une fois les configurations exportées, l'interface d'administration bloque la configuration aux utilisateurs.

Il faut noter un changement dans l'enregistrement des tableaux de valeurs : comme les valeurs sont stockées sous forme de chaines, dans Magento inférieur à 2.2, les tableaux étaient sérializés, ils sont désormais encodés en JSON.

Priorités

Si dans les précédentes versions de Magento, les configurations définies dans la base de données avaient le plus de poids, c'est l'inverse qui se passe dans Magento 2.2.

  • Est ce que la valeur est définie dans env.php ?
    • Oui → valeur utilisée
    • Non, est ce que la valeur est définie dans config.php ?
      • Oui → valeur utilisée
      • Non, est ce que la valeur est définie dans la base de données ?
        • Oui → valeur utilisée
        • Non → valeur par défaut

Les configurations des modules sont désormais reportées dans env.php ou config.php selon leurs sensibilités et leurs portées.

Versionning

Afin de faciliter le versionning, il est recommandé de suivre les conseils suivants :

  • env.php
    • Ne pas versionner ce fichier car il est spécifique à un environnement donné
    • Il est préférable de versionner des fichiers env.php pour chaque environnement (env.php.local, env.php.prod par exemple)
    • Et de remplacer env.php directement au sein de l'environnement lors d'un déploiement
  • config.php
    • Ce fichier est versionné car il contient des configurations génériques
    • Après mise en place dans son environnement, la commande CLI app:config:import peut être lancée afin de récupérer la nouvelle version de configuration (cette commande est lancée lorsque la commande setup:upgrade)

Modifications

Lorsque l'on souhaite modifier une configuration, on ne peut plus utiliser directement l’administration de Magento car celle-ci est bloquée par la commande app:config:dump.

On peut désormais définir les configurations via les commande CLI config:set et config:sensitive:set ou directement en éditant les fichiers env.php et config.php.

Avantages et inconvénients, conclusions

Avantages

Ce nouveau système permet d'améliorer la rapidité du déploiement de Magento 2.2 ainsi que de réduire le downtime qui lui est propre.

Les fichiers env.php et config.php permettent une gestion facilitée de la configuration entre les développeurs d'un projet et les différents environnements sur lesquels il sera mis en place.

Avant Magento 2.2, lorsqu'un développeur devait mettre en place une configuration, il était nécessaire de mettre en place un script d'installation (setup install) afin de transmettre ces modifications aux autres développeurs et sur les environnements d'installation. Ces fichiers d'installation sont plutôt pénibles à écrire. Avec la version 2.2, il n'est plus nécessaire d'en écrire car le développeur peut simplement ajouter sa valeur au fichier conf.php et la partager via Git.

Inconvénients

Il est possible que les développeurs rencontrent des diff lors d'un commit sur Git, pas toujours trivial à résoudre.

Les développeurs ne doivent pas oublier d'importer les dernières valeurs de configuration après un pull, sous peine de créer des diff lors d'un commit suivant.

L'édition des valeurs de type tableau peut se révéler compliquée si on ne connait pas sa structure.

Conclusions

Globalement, la nouvelle gestion des configurations de Magento 2.2 facilite le travail des différents membres d'un projet.

Toutefois il a été constaté certains inconvénients comme la difficulté de modifier les clés de type tableau et le blocage dans l'administration qui peut s'avérer gênant quand un client final souhaite lui-même modifier sa configuration.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *