Module Initialization (Magento Certified Developer Exam)

December 27, 2012 Andrei Danilchyk Certification
Module Initialization (Magento Certified Developer Exam)

This post covers a simple and, at the same time, a very important topic of module initialization in Magento. No extension can be developed without knowledge about it. As a rule, a developer takes a ready-to-use initialization template without even knowing how it works. That is why I want to provide a detailed picture of the correct way to initialize your module and construct complex systems of several dependent extensions.

So, here we go. Initialization of every module as well as “building” of the whole Magento configuration starts in the “magical” app/etc folder. Even earlier, to be more specific – from the Mage::run() method in the index.php file:

Module Initialization

Let’s take a closer look at App.php (the Mage_Core_Model_App class) and the run(..) method:


Here is the $this->_initModules() method and its code in the Mage_Core_Model_App class:


Our ultimate goal is the $this->_config->loadModules() method, wherein $this->_config = new Mage_Core_Model_Config($options) (from Mage.php).

This method itself collects and initializes all the Magento modules. Many of them depend on each other and are a part of each other.  Let’s take a look at the method mentioned above – the one from the Mage_Core_Model_Config class.


After following a simple methods chain, we get to the _getDeclaredModuleFiles() method. It consists of the several stages:

  1. XML files names capturing from the [magento root]/app/etc/modules folder.
  2. Combining them into an array, sticking to the particular order.

Regarding this order, I cannot but mention that XML file named Mage_All always goes first. It contains all the Magento extensions initialization. Next XML files with the “Mage_” prefix are added, i.e. all the less important Magento modules. All the custom modules with any name of the XML file go at the end.

So, let’s proceed with the _loadDeclaredModules() method code:


Everything is trivial here: we collect content of file and array we’ve mentioned above and add it to $unsortedConfig. Why it’s ‘unsorted ‘will be clarified in the subsequent description.

One would think, the goal is achieved and initializations file is assembled. Magento, however, has one very convenient tool to change the module initialization order. It becomes essential if modules depend on each other. Let’s take a look at the example of the Mage_Catalog module initialization structure in the Mage_All.xml file:


Wherein <active>true</active> (can have true/false values) is used for module activation, <codePool>core</codePool> (core/local/community) determines the pool module will be located in; <Mage_Catalog>…</Mage_Catalog> is both module’s name and path to the pool location. This module will be therefore located in:


There is one more structure defining the module initialization order:

I.e., the module follows the Mage_Eav, Mage_Dataflow, Mage_Cms, Mage_Index modules (if they are present). If the extension is enabled in the absence of one of the modules above, we will get the exception:

So, there is the <depends> construction, but how is its processing and module declaring sorting implemented? Let’s use the _loadDeclaredModules() method again:


As we can see, the $moduleDepends array, made up of $unsortedConfig, is prepared and passed into the _sortModuleDepends() method – the main sorting method based on the <depends> construction. Let’s consider this method in more detail:


It’s checked here if the modules, the current extension depends on, are present and active. If this condition is met

the exception, mentioned above, happens to be.

It’s followed by the sorting process itself:

And finally – the sorting “quality review”. Modules compatibility bugs are reported here. Typical bug is compatibility of two extensions. It’s impossible to define the order of these modules and the exception is being called.

It’s all sorted (taking <depends> into account) and we return to the  _loadDeclaredModules method again:


So, the finite-length sequence of module declarations is formed, but it’s just a small part of the Magento module general configuration formation process. It’s next necessary to build each module’s configuration into the local configuration XML file, located in every extension.

Let’s go back the loadModules() method again:


I’ll leave the loadModulesConfiguration() method details out of this post, dwelling on two small issues only:


Here is where Magento verifies the <active> node value for the current module. It’s also checked if configuration of modules that are in the ‘local’ pool should be built. $module->is(‘active’) will return false only if the <active> value is false, off or this node doesn’t exist (/app/code/core/Mage/Core/Model/Config/Element.php). All other cases will activate the module.

Let’s turn our attention to the _canUseLocalModules() method:


The method checks if the <disable_local_modules> node configurations are in the ‘global’ branch. If they are present, its value is being used. Magento thereby can disable all the modules from the ‘local’ pool with the help of the <disable_local_modules> directive.

The next interesting thing for us in loadModulesConfiguration():


Next, the method collects all the files (config.xml in our case) from the /etc extension folder and unites them into the returned object. Configuration formation seems to be over, but there is another essential moment, somehow related to module initialization – repeated addition of the  [magento root]/app/etc/local.xml file content to the already built configuration.


It helps redefine all the most important nodes playing the key role in Magento functioning (table_prefix or database accesses, for instance) in case these nodes were defined in some modules configuration.

Resuming, let’s define the main stages of module initialization in Magento:

  1. XML files names capturing from the [magento root]/app/etc/modules folder and combining them into an array, sticking to the particular order:
    • Mage_all
    • Mage_
    • All the rest
  2. Modules sorting inside the object depending on the <depends> directive.
  3. Collecting the local configuration XML files in each module sticking to the particular order in light of  <active> and <disable_local_modules> directives and its addition to the general configuration object.
  4. Repeating the /app/etc/local.xml file content uploading to the general configuration.


  1. Denisa, configuration files from /app/etc are loaded in the Mage_Core_Model_Config::loadBase(). If you go through the whole request path it should be Index.php – Mage::run() (Mage::app()) – Mage_Core_Model_App::run() – Mage_Core_Model_App::run() – Mage_Core_Model_App::baseInit() – Mage_Core_Model_Config::loadBase().

    You can check my articles about Magento Configuration flow: Explaining how Magento Loads and Manipulates Configuration Information part 1 and part 2

    Also you can look at the Magento Request Flow Diagram

Post a new comment

BelVG Newsletter
Subscribe to our mailing list and get interesting stuff and updates to your email inbox.
Email *