Présentation des fichiers de configuration de module
Les responsabilités du fichier de configuration config.xml
utilisé dans les versions antérieures de Commerce sont désormais réparties entre plusieurs fichiers situés dans différents répertoires de module. Le Commerce plusieurs fichiers de configuration charge à la demande uniquement lorsqu’un module demande un type de configuration spécifique.
Vous pouvez utiliser ces fichiers, également appelés types de configuration, pour personnaliser des aspects spécifiques du comportement de votre module.
Plusieurs modules peuvent déclarer des fichiers de configuration qui affectent le même type de configuration (des événements, par exemple), et ces fichiers de configuration multiples sont fusionnés.
Vous trouverez ci-dessous les termes courants utilisés dans cette rubrique :
-
Objet de configuration : bibliothèque ou classe Commerce chargée de définir et de valider le type de configuration. Par exemple, l’objet de configuration pour
config.xml
est Magento\Framework\App\Config. -
Étape de configuration : les étapes sont définies comme primaire, global et area. Chaque étape détermine le moment où le type de configuration est chargé et fusionné avec les types de configuration du même nom. Par exemple, les fichiers
module.xml
sont fusionnés avec d’autres fichiersmodule.xml
. -
Étendue de configuration : Complémentaire aux étapes de configuration, une étendue définit le modèle de type de configuration. Par exemple,
adminhtml
est une portée de zone qui est chargée avec à l’étape avec les configurationsadminhtml
d’autres modules. Pour plus d’informations, voir Modules et zones.
Chargement et fusion des configurations
Cette section explique comment les fichiers de configuration sont chargés et fusionnés.
Comment Commerce charge les fichiers de configuration
Commerce charge les fichiers de configuration dans l’ordre suivant (tous les chemins d’accès dépendent du répertoire d’installation de Commerce) :
- Configuration de Principal (app/etc/di.xml). Ce fichier est utilisé pour démarrer Commerce.
- Configurations globales des modules (
<your component base dir>/<vendorname>/<component-type>-<component-name>/etc/*.xml
). Collecte certains fichiers de configuration de tous les modules et les fusionne. - Configuration spécifique à la zone à partir des modules (
<your component base dir>/<vendorname>/<component-type>-<component-name>/etc/<area>/*.xml
). Collecte des fichiers de configuration de tous les modules et les fusionne dans la configuration globale. Certaines configurations spécifiques à une zone peuvent remplacer ou étendre la configuration globale.
where
-
<your component base dir>
est le répertoire de base dans lequel se trouve votre composant. Les valeurs types sontapp/code
ouvendor
par rapport au répertoire d’installation de Commerce. -
<vendorname>
est le nom du fournisseur du composant ; par exemple, le nom du fournisseur Commerce estmagento
. -
<component-type>
est l’un des suivants :module-
: extension ou module.theme-
: thème.language-
: package de langue.
<magento_root>/app/design/frontend
ou <magento_root>/app/design/adminhtml
.<component-name>
: nom de votre composant tel que défini dans compositeur.json.
Fusion du fichier de configuration
Les noeuds des fichiers de configuration sont fusionnés en fonction de leurs XPath entièrement qualifiés, qui a un attribut spécial défini dans le tableau $idAttributes
déclaré comme identifiant. Cet identifiant doit être unique pour tous les nœuds imbriqués sous le même nœud parent.
Algorithme de fusion d’applications commerciales :
- Si les identificateurs de nœud sont égaux (ou si aucun identificateur n’est défini), tout le contenu sous-jacent du nœud (attributs, nœuds enfants et contenu scalaire) est remplacé.
- Si les identifiants de nœud ne sont pas égaux, le nœud est un nouvel enfant du nœud parent.
- Si le document d’origine comporte plusieurs nœuds avec le même identificateur, une erreur est déclenchée car les identificateurs ne peuvent pas être distingués.
Une fois les fichiers de configuration fusionnés, le document résultant contient tous les nœuds des fichiers d’origine.
Types de configuration, objets et interfaces
Les sections suivantes fournissent des informations sur les types de configuration, leurs objets de configuration correspondants et les interfaces que vous pouvez utiliser pour utiliser les objets :
Types et objets de configuration
Le tableau suivant montre chaque type de configuration et l’objet de configuration Commerce auquel il se rapporte.
address_formats.xml
analytics.xml
catalog_attributes.xml
config.php
et env.php
communication.xml
eav_attributes.xml
email_templates.xml
esconfig.xml
extension_attributes.xml
fieldset.xml
menu.xml
module.xml
product_options.xml
queue_consumer.xml
queue_publisher.xml
queue_topology.xml
resources.xml
search_engine.xml
search_request.xml
sections.xml
system.xml
validation.xml
view.xml
webapi_async.xml
zip_codes.xml
Interfaces de configuration
Vous pouvez interagir avec les fichiers de configuration à l’aide des interfaces sous Magento\Framework\Config.
Vous pouvez utiliser ces interfaces si vous créez un type de configuration.
Magento\Framework\Config
fournit les interfaces suivantes :
- Framework\Config\ConverterInterface, qui convertit le XML en une représentation matricielle en mémoire des configurations.
- Framework\Config\DataInterface, qui récupère les données de configuration dans une étendue spécifiée.
- Framework\Config\FileResolverInterface, qui identifie l’emplacement des fichiers à lire par Magento\Framework\Config\ReaderInterface.
- Framework\Config\ReaderInterface, qui lit les données de configuration du stockage et sélectionne le stockage à partir duquel elles lisent.
C’est-à-dire que le système de fichiers, la base de données, l’autre stockage fusionne les fichiers de configuration conformément aux règles de fusion et valide les fichiers de configuration avec les schémas de validation.
- Framework\Config\SchemaLocatorInterface, qui localise le schéma XSD.
- Framework\Config\ScopeListInterface, qui renvoie une liste de portées.
- Framework\Config\ValidationStateInterface, qui récupère l’état de validation.