Customize Parts Of Magento Configuration

Last modified by chris.mcmacken on Fri, June 25, 2010 09:04
Source|Old Revisions  

This is an old revision of the document!


This page intended to give overview and clarify details of customizations for various parts of modules’ configuration.

How is the configuration generated?

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:
<?xml version="1.0"?>
<config>
  <node1>
    <node1_1>Data1</node1_1>
  </node1>
  <node2>Data2</node2>
</config>
  • Source file 2:
<?xml version="1.0"?>
<config>
  <node1>
    <node1_2>Data3</node1_2>
  </node1>
  <node2>Data4</node2>
  <node3>Data5</node3>
</config>
  • Merged result:
<?xml version="1.0"?>
<config>
  <node1>
    <node1_1>Data1</node1_1>
    <node1_2>Data3</node1_2>
  </node1>
  <node2>Data4</node2>
  <node3>Data5</node3>
</config>

As you can see the merged XML structure consists of source file 1 contents, appended or overwritten (see node2, Data4) by source file 2.

Which files are used in configuration?

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.
  • Load app/etc/config.xml. This file contains values absolutely necessary for successful load of Magento core components.
  • Merge all files from app/etc/modules/ (app/etc/modules.xml until 0.6.14100). Files containing modules declarations are dropped here by the core, community and custom packages installed, and are named by package name (Mage_All.xml).
  • Merge app/etc/local.xml. Contains settings for local database connections, installation date and local encryption key.
  • If app/etc/local.xml was not found (not installed yet) app/etc/distro.xml is merged. Contains auto-configured values to be used in installation wizard.
  • Merge config.xml from all the modules that were declared in app/etc/modules/*. These are: app/code/{codePool}/{companyName}/{moduleName}/etc/config.xml

Models

Models are classes that define abstract or resource specific logic. Here’s how we are going to declare a new module functionality:

Create app/etc/modules/Example_Module.xml:

<?xml version="1.0"?>
<config>
  <modules>
    <Example_Module>
      <codePool>local</codePool>
      <active>true</active>
    </Example_Module>
  </modules>
</config>

Create app/code/local/Example/Module/etc/config.xml:

<?xml version="1.0"?>
<config>
  <global>
    <models>
      <example_mod>
        <class>Example_Module_Model</class>
      </example_mod>

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.

Customization

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 app/etc/modules/Example_Module.xml.

app/code/local/Example/Custom/etc/config.xml:

  • 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:
<?xml version="1.0"?>
<config>
  <global>
    <models>
      <example_mod>
        <class>Example_Custom_Model</class>
      </example_mod>
  • Overriding just one class:
<?xml version="1.0"?>
<config>
  <global>
    <models>
      <example_mod>
        <rewrite>
          <test_model>Example_Custom_Model_Test_Model</test_model>
        </rewrite>
      </example_mod>

app/code/local/Example/Custom/Model/Test/Model.php could look like that:

<?php

class Example_Custom_Model_Test_Model extends Example_Module_Model_Test_Model
{
  public function exampleMethod()
  {
    return 'custom result';
  }
}

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 exampleMethod.

Helpers

Helper is a support class for performing some specific manipulations with data in *.phtml templates or in *.xml layouts

$this->helper('wishlist'); // wishlist module; data.php helper
$this->helper('catalog/image'); //catalog module; image.php helper
$this->helper(); //current module; data.php helper

Helpers also usefull for caching purposes (see core/Mage/Core/Helper/Abstract.php)

Blocks

Controllers

Resources

These are overloaded in similar ways as models. These are the data persistence resources used by the system’s data mapper. Also business logic for model collections are encapsulated in collection resources. All data access funnels down thru the resources from the models ( or controllers, if business logic is being defined in a page controller )

Themes (layouts, templates, css and images)

this is just a test of theme

Admin Menu and ACL

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 XML merged in. Have not tested beyond hard coding changes.

Admin configuration fields




 

Magento 2 GitHub Repository

Magento Job Board - Some sort of tag line goes here

Latest Posts| View all Jobs