Magento 2: The Organizing of Magento’s Global Configuration

While the concept of The Global Config still exists in Magento, a module’s etc/config.xml is no longer the place where developers will enter most of a module’s configuration. In fact, if you try to use a Magento 1 config.xml file in Magento 2 and turn on developer mode, you’ll be greeted by the following.

Invalid XML in file /magento2/app/code/Packagename/Modulename/etc/config.xml: Element ‘modules’: This element is not expected. Expected is one of ( default, stores, websites ). Line: 3

That is, the only top level nodes allowed are <default/>, <stores/>, and <websites/>. The config.xml file has gone back to its roots, and may only be used to set defaults or scope specific values for the System Configuration variables.

So does that mean Magento’s greatly simplified its module system such that it no longer needs configuration?

No.

Instead, all module configuration has been broken out into individual configuration files. For example, if you take a look at the Magento_Core module, you’ll see the following configuration files

etc/cache.xml
etc/config.xml
etc/crontab.xml
etc/di.xml
etc/events.xml
etc/frontend/di.xml
etc/frontend/events.xml
etc/frontend/routes.xml
etc/module.xml
etc/resources.xml

Events have their own events.xml file — including an individual events.xml file for the frontend area. There’s di.xml files for dependency injection (Magento 2’s superior replacement for the class rewrite system), the old <routers/> nodes are now routes.xml, etc.

This change started in Magento 1, but Magento 2 makes it mandatory. Old configuration nodes in config.xml are ignored, and developer mode enforces a strict format on the XML configuration files.

Making things extra tricky for folks migrating modules to Magento 2, the syntax of these files is different from Magento 1. For example, an event observer in Magento 1 looked like this

<catalog_prepare_price_select>
    <observers>
        <weee>
            <type>model</type>
            <class>weee/observer</class>
            <method>prepareCatalogIndexSelect</method>
        </weee>
    </observers>
</catalog_prepare_price_select>

In Magento 2, an observer looks like this

<event name="catalog_entity_attribute_save_before">
    <observer name="weee" instance="MagentoWeeeModelObserver" method="assignBackendModelToAttribute" shared="false" />
</event>

While not the most existing task in the world, migrating your configuration files to this new format is a step in the right direction. Magento 1’s config.xml files could, over time, become unwieldy. Beyond reducing system complexity, this re-organization will help shed light on inefficient parts of Magento’s configuration system, and make individual sub-systems easier targets for refactoring efforts.

With any luck, tools will crop up for automatic migration, or maybe eBay/Magento will release their own, internal conversion scripts.