Define your configuration files
Each Magento 2 module has its own set of configuration files, gathered into the module鈥檚 etc/
directory.
Unlike Magento 1, there is no monolithic configuration file in Magento 2.
Root directory
We refer to a component鈥檚 root directory as the top-level directory in which you develop component code. Typically, this directory is located in one of the following directories relative to the Magento root directory:
-
Subdirectory of
app
(recommended.) :- For modules, use
app/code
- For themes, use
app/design/frontend
(storefront theme) orapp/design/adminhtml
(Magento Admin theme) - For language packages, use
app/i18n
You can easily set up this type of environment by cloning the Magento 2 GitHub repository. Typically, you cloned the repository if you want to to contribute code to the Magento 2 codebase.
- For modules, use
-
vendor
: You get this directory structure if you used thecomposer create-project
command to get a Magento 2 metapackage (which downloads the CE or EE code), or if you extracted a compressed Magento 2 archive.
Required files
The following are required for all components:
registration.php
: Among other things, specifies the directory in which the component is installed; by default, components install in the<Magento root dir>/vendor
directory. For more information, see Component registration.composer.json
: Specifies component dependencies. For more information, see Composer integration.
Use /etc for your configuration files
Magento 2 looks for configuration information for each module in that module鈥檚 etc
directory. Depending on the needs of your module, you might have the following configuration files at the top level of your module鈥檚 etc
directory:
- acl.xml
- config.xml
- di.xml
- module.xml
- webapi.xml
Additions you make to those configuration files are applied globally to your module.
In addition to those files, a Magento 2 module also has nested configuration directories in the etc
directory for any required administration html, frontend, API REST, or API SOAP specific configuration. Additions you make to files in these directories override the settings in the global configuration files for the respective functionality only. That is, if you add a config.xml
file to etc/frontend
, the settings you make in that file overrides the settings in etc/config.xml
for storefront functionality only.
<your module root dir>/etc/adminhtml/
<your module root dir>/etc/frontend/
<your module root dir>/etc/webapi_rest/
<your module root dir>/etc/webapi_soap/
Configuration files
- Configuration files that are in the top level of that module鈥檚
etc
directory are global to that component. - Configuration files placed in subdirectories (
adminhtml
,frontend
,webapi_rest
,webapi_soap
) apply only to those respective functional areas.
Tailor your configuration files for what your module does
The exact set of configuration files required for your module depends on what your new module does. The required configuration files depend on how you plan to use the module: will the module be manifested on the storefront UI, or in the Magento Admin panel, or as a backend extension that makes a service call? Or all of the above. For example, if your module performs a function in the Admin, you should add any necessary configuration files for those functions to etc/adminhtml/
, like:
<your module root dir>/etc/adminhtml/di.xml
<your module root dir>/etc/adminhtml/routes.xml
Similarly, if your module changes the UI, you should add the needed configuration files to ~/etc/frontend/
. For example:
<your module root dir>/etc/frontend/.xml
<your module root dir>/etc/frontend/page_types.xml
If the module is a service that may call an API, or does some other work that is not manifested in the UI you should add any needed configuration files in the REST and/or SOAP webapi configuration directories, like this:
<your module root dir>/etc/webapi_rest/di.xml
<your module root dir>/etc/webapi_soap/di.xml
Keep in mind that you might be able to handle your module鈥檚 configuration solely with configuration files at the top level of your module鈥檚 etc
directory, but the nested directory is a useful way to keep the configuration neatly compartmentalized.
Find us on