This page intended to give overview and clarify details of customizations for various parts of modules’ configuration.
To achieve maximum flexibility of configuration without need for manual editing of configuration files, Magento utilizes a concept of merging the configuration from multiple XML files into one global cached configuration repository.
As an example, let’s see how 2 simple source xml files merge into one:
Source file 1:
Source file 2:
As you can see the merged XML structure consists of source file 1 contents, appended or overwritten (see node2, Data4) by source file 2.
Refer to: app/code/core/Mage/Core/Model/Config.php, method init()
- If usage of config cache is enabled, Magento will try to load the configuration from cache. If loaded successfully, it will skip all the following steps.
app/etc/config.xml. This file contains values absolutely necessary for successful load of Magento core components.
- Merge all files from
app/etc/modules.xmluntil 0.6.14100). Files containing modules declarations are dropped here by the core, community and custom packages installed, and are named by package name (
app/etc/local.xml. Contains settings for local database connections, installation date and local encryption key.
app/etc/local.xmlwas not found (not installed yet)
app/etc/distro.xmlis merged. Contains auto-configured values to be used in installation wizard.
config.xmlfrom all the modules that were declared in
app/etc/modules/*. These are:
Models are classes that define abstract or resource specific logic. Here’s how we are going to declare a new module functionality:
This will allow usage of
$obj = Mage::getModel(’example_mod/test_model’) and will return an instance of the class
Example_Module_Model_Test_Model, located in
app/code/local/Example/Module/Model/Test/Model.php. As you can see,
example_mod is replaced with
Example_Module_Model and together with
test_model generate name of required class.
If we want to be able to upgrade our modules without need of manual code changes, and given that developers’ discipline is ensured, it is possible to override functionality without changing any existing files. In our example we will create a new module
Example_Custom that will override
Example_Module functionality. Declaring the module is similar to
- Overriding the whole model group. Please note that in this case you will need to provide ALL classes in your custom module, that exist in original, to make sure that application won’t break:
- Overriding just one class:
app/code/local/Example/Custom/Model/Test/Model.phpcould look like that:
Now, everywhere in the code
$obj = Mage::getModel(’example_mod/test_model’) will return an instance of
Example_Custom_Model_Test_Model with all original functionality of
Example_Module_Model_Test_Model and custom
Helper is a support class for performing some specific manipulations with data in *.phtml templates or in *.xml layouts
Helpers also usefull for caching purposes (see core/Mage/Core/Helper/Abstract.php)
Also see Changing and Customizing Magento Code.
Admin menu is setup in app/code/core/Mage/Adminhtml/etc/config.xml Copy & paste an existing XML chunk and customize for your needs. You can supposedly put this in any other configuration file ( think a user created module ) & have the XMLmerged in. Have not tested beyond hard coding changes.