Magento module configuration file reference

POSTED ON Aug 31, 2010 IN in How To

The most important file in custom modules development is config.xml. With the help of this file you can override models, blocks, helpers; define custom controllers, module version, table names, cache types; load your layout files, etc. About all of these you will learn from the article.

Module bootstrap and configuration files load order

The module configuration file will not be loaded without a bootstrap file. The bootstrap files of modules are placed in app/etc/modules. Usually all of them are named the same as the module. But you can define more than one module in file, such an example is placed in Mage_All.xml file. The basic structure of a boostrap file:

<?xml version="1.0"?>
<config>
    <modules>
          <Namespace_Modulename>
                 <codePool>local</codePool> <!-- local or core or community -->
                 <active>true</active> <!-- true or false -->
                 <depends>
                       <Namespace_Modulename1 />
                       <Namespace_Modulename2 />
                       <Namespace_Modulename3 />
                 </depends>
          </Namespace_Modulename>
    </modules>
</config>

The description of each node you can find in the following list:
Click on the node name to see its description

  • modules
    All the modules are placed under this node, the node content is merged from all the bootstrap files into the one structure. If you have added new module boostrap file, but it will not show up. Just refresh the cache, because the merged structure is cached by default.
    • [Namespace_Modulename]
      The name of this node defines the module namespace path. Of course you can use structure with more than one underline character, but the best practice to camelize module names that contain more than one word. For example, EcomDev_ProductPageShipping and EcomDev_Product_Page_Shipping is allowed, but the first one is preferable, because each underline character equals to slash in directory structure.
      • codePool
        This node defines the code pool of the module. Possible values are core, community and local. These values are the names of the folders in app/code directory. All the modules from Magento Inc. core team usually are placed in core. Community should contain Magento Connect extensions . Local usually is used to perform some local modifications.
        This node is required.
      • active
        Module activity indicator, if you do not specify the node value, it will be disabled by default. Possible values are true and false.
      • depends
        This node specifies dependencies and load order of the module. If your module requires another one or need to be loaded only after it, you should just mention it as a child node. The system will rise an error if the required module does not exist or is not activated.

You may have already noticed that if you place some configuration nodes like in module config.xml file, it will not affect on the configuration. The module bootstrap file is created only to define module initialization values, it is not the actual configuration file.

Module main configuration file

Each Magento module has its main configuration file (etc/config.xml), that contains definitions of models & blocks namespaces, controller routes, database resources, layout file paths, etc.
Take a look at the following example of a simple configuration file:

<?xml version="1.0" ?>
<config>
    <modules>
        <Namespace_Modulename>
            <version>1.1.1</version> <!-- the version of module resources -->
        </Namespace_Modulename>
    </modules>
    <global> <!-- global scope, also known as the default configuration area -->
         <models> <!-- definitions of the module models namespaces -->
             <namespace_modulename>
                 <class>Namespace_Modulename_Model</class>
                 <!-- definition of model resource model -->
                 <resourceModel>namespace_modulename_resource</resourceModel>
             </namespace_modulename>
             <namespace_modulename_resource>
                 <class>Namespace_Modulename_Model_Resource</class>
             </namespace_modulename_resource>
         </models>
         <blocks> <!-- a defintion of the module blocks namespace -->
             <namespace_modulename>
                 <class>Namespace_Modulename_Block</class>
             </namespace_modulename>
         </blocks>
         <helpers> <!-- a definition of the module helpers namespace -->
             <namespace_modulename>
                 <class>Namespace_Modulename_Helper</class>
             </namaspace_modulename>
         </helpers>
         <resources> <!-- a resource setup files path defintion -->
             <namespace_modulename_setup>
                 <setup>
                     <module>Namespace_Modulename</module>
                     <class>Namespace_Modulename_Model_Resource_Setup</class>
                 </setup>
             </namespace_modulename_setup>
         </resources>
         <events>
             <event_name>
                 <observers>
                      <unique_observer_name>
                          <!-- or you can specify class node, it is the same as model -->
                          <model>namespace_modulename/observer</model>
                          <method>listenerMethodName</method>
                      </unique_observer_name>
                 </observers>
             </event_name>
         </events>
    </global>
    <frontend>
         <layout> <!-- definition of layout update for frontend area -->
             <updates>
                 <unique_update_name>
                     <file>namespace/modulename.xml</file>
                 </unique_update_name>
             </updates>
         </layout>
    </frontend>
</config>

This file defines the module with own models, blocks, helpers, a resource setup, a frontend layout update and one event observer in the global scope. I hope it will not confuse you and you are already familiar with such words those are used here.

The description of nodes those are the most used during custom modules development. I have summarized them by categories and areas where they are used.

General configuration values

Click on the node name to see its description

  • modules

    The same node as in bootstrap file, but you cannot disable or add modules here, because the processing of such values goes before configuration merging.
    • [Namespace_Modulename]

      The module path
      • version

        Version of module resource installment, if you do not use resource install, you can skip the definition of the modules node.
  • global

    Global configuration scope. Contains definitions that should be shared between all scopes.
    • models

      This node contains definition of all module models. If you have not specified your model namespace here, Magento will use Mage namespace for class loading. It works in the same manner for blocks and helpers.
      • [namespace_modulename]

        The node name specifies the model namespace. The namespace is used in Mage::getModel() method before slash character.
        • class

          Specifies the class prefix that will be used for model namespace.
          For example:
          With such a configuration

                  <models>
                      <custom_module>
                          <class>Custom_Module_Model</class>
                      </custom_module>
                  </models>
          

          running of the following code

          $model = Mage::getModel('custom_module/model_name');
          

          will return an instance of Custom_Module_Model_Model_Name class.

        • resourceModel

          The node value specifies resource model namespace that should be used for a standard model. Resource models are defined in the same manner as standard ones.
        • entities

          This node used only in definition of resource models to specify table names used for models.
          • [entity_name]

            The node name specifies the entity table name used in methods of a model.
            • table

              The node value specifies the database table name mapped to the entity table name
        • rewrite

          This node used to override a model by specifying its full class name.
          • [model_name]

            The node name specifies the model name to override. The node value contains a full class name that will be used to create a model instance.
            For example:
            With such a configuration

                    <models>
                        <catalog>
                            <rewrite>
                                 <product>Custom_Module_Model_Product</product>
                            </rewrite>
                        </catalog>
                    </models>
            

            running of the following code

            $product = Mage::getModel('catalog/product');
            

            will return an instance of Custom_Module_Model_Product class instead of Mage_Catalog_Model_Product.

    • blocks

      This node contains definition of all module blocks. It have the same configuration rules as model, so the node description is omitted.
      • [namespace_modulename]

        • class

        • rewrite

          • [block_name]

    • helpers

      This node contains definition of all module helpers. It have the same configuration rules as model, so the node description is omitted.
      • [namespace_modulename]

        • class

        • rewrite

          • [helper_name]

    • resources

      This node contains configurations of database resources for resource models
      • [resource_name]

        The node name specifies the name of resource that is used in a resource model.
        • connection

          This node is used to specify the connection settings for a database. If you have not specified it, the default connection will be used.
          • use

            The node value specifies another resource connection for the current. In Magento default_read and default_write resources use default_setup connection. You can specify your own connection settings for them in your module configuration or app/etc/local.xml file.
          • model

            The model of database resource. By default is set to mysql4. It is used as the file prefix to indicate which files can be processed by a setup model. It means that you can create different setup scripts for different DB vendors.
          • [connection_config_field]

            The node name specifies the configuration field name for a database adapter. Possible values can be found in Zend_Db_Adapter reference.
        • setup

          This node contains configuration of a resource setup.
          • module

            The node value specifies the module that will be used for setup. If you do not specify it, your setup scripts will not be applied.
          • class

            The node value specifies the class that will be used as the setup model for a resource. If you do not specify it, Mage_Core_Model_Resource_Setup will be used as the setup model.
    • events

      Definition of event observers for global scope. See this section for details
    • fieldsets

      Definition of the fields map for coping of data between different Magento entities. The children nodes are used by copyFiledset method in Mage_Core_Helper_Data class. Also you can find non usual usage of such node in Customer module, where this node indicates which fields is allowed for updating in customer account to prevent security issues.
      • [fieldset_name]

        The name of this node is the fieldset name. It is passed as the first argument to copyFieldset method.
        • [source_field_code]

          The node name is the field name to copy. It is used to retrieve field value from the source object or array in copyFieldset method.
          • [aspect]

            The node name indicates an aspect of the field coping. The value specifies destination field name. If the field name need to be the same in the destination as in the source, just specify a wildcard character (*) in the node value. The aspect passed as the second argument to copyFieldset method, so if do not specify an aspect for the field it wont be copied in the destination object.
            In Customer Module with fieldset ‘custome_account’ this field indicates allowed actions for attribute. If a field is placed in the form on the account page but not mentioned in fieldset, it will not be saved.
    • template

      This node contains definitions of transactional email templates.
      • [template_code]

        The node name specifies unique template code that can be used in Mage_Core_Model_Email_Template::loadByCode() method. Usually it also indicates the configuration path of the template, because Mage_Adminhtml_Model_System_Config_Source_Email_Template uses it as default value. So you should notice that if you create your custom template, that will be placed in app/locale/[LOCALE_CODE] and can be changed by customer in transactional emails, you need to take about its name in configuration. For example your configuration for selection of a template is placed here ‘sales_emails/order/template’ the name for such template should be ‘sales_emails_order_template’.
        • label

          The node value specifies the template name in the template drop-down on the transactional email edit page. If you want to make this value translatable, you need to specify module and translate attributes in [template_code] node. Module attribute should contain namespace of the module helper. Translate attribute should contain the name of a node which value should be translated.
        • file

          The node value specifies the template file path. This path is relative to app/locale/[LOCALE_CODE] directory.
        • type

          The node value indicates what type of content will be sent in the email. Possible values are html and text.
    • cache

      The node contains configurations of Magento cache. Configurations of cache adapters usually are placed in app/etc/local.xml
      • backend

        The node value specifies cache adapter for Magento. Possible values are sqlite, memcached, apc, xcache, eaccelerator, database, file. Also you can specify class name of your custom backend or one of Zend_Cache backend class names. By default it is file backend.
      • backend_options

        The node contains backend options for cache adapter. Possible backend options can be found at Zend_Cache reference.
        • [option_code]

          The node name specifies code of the option. The node itself specifies option value.
      • slow_backend

        The node value specifies cache adapter for Magento that will be used if standard cache backend is unavailable. Possible values are database, file. Also you can specify class name of your custom backend or one of Zend_Cache backend class names. This node should be used if you are using apc, memcache, eaccelerator, etc as standard backend. By default it is file backend.
      • slow_backend_options

        The node contains backend options for slow cache adapter. Possible backend options can be found at Zend_Cache reference.
        • [option_code]

          The node name specifies code of the option. The node itself specifies option value.
      • memcached

        This node contains options for memcached backend type. If you are using it backend_options wont work, because it is overridden by this node. Also it can include options for slow backend.
        • servers

          This node contains definitions of memcache server connections.
          • server

            The node contains credentials for a connection to the memcache server.
            • host

              The node value specifies memcached server host.
            • port

              The node value specifies memcached server port.
            • persistent

              The node value specifies memcached server connection persistence.
            • weight

              The node value specifies memcached server weight, eg. priority.
            • timeout

              The node value specifies memcached server connection timeout.
            • retry_interval

              The node value specifies memcached server connection retry interval.
            • status

              The node value specifies memcached server activity, if it equals to 1 this server will be used.
      • types

        The node children are possible types for cache. All of them presented on Cache Management page in backend.
        • [type_code]

          The node name specifies unique code for a cache type, adding of a custom cache type is described in previous blogpost.
          • label

            The node value specifies the cache type name on Cache Management page. If you want to make this value translatable, you need to specify module and translate attributes in [type_code] node. Module attribute should contain namespace of the module helper. Translate attribute should contain the name of a node which value should be translated.
          • description

            The node value specifies the cache type description on Cache Management page. It has the same translate rules as label node.
          • tags

            The node value specifies the cache tags those are associated to this cache type. If cache type is cleared all the cache that is tagged with these tag will be cleared too. Tag names are separated by comma.
      • session_save

        The node value specifies type of session save handler. There are three options: db, memcahe, files.
      • session_save_path

        The node value specifies path for saving of session data. For memcache you should specify server URI.
      • session_cache_limiter

        The node value specifies type of session cache limitations. Possible values are public, private_no_expire, private, nocache. Refer to PHP Manual for details.
      • session

        This node should contain options related to session configuration, but contains only user agent session validation excludes.
        • validation

          This node contains session validation options.
          • http_user_agent_skip

            This node contains list of user agents that should be skipped during the session validation. It contains all possible flash player user agent names. Because it does not handle cookies during the file upload.
            • [internal_user_agent_code]

              The node name contains internal code of user agent, system does not check it. The value contains substring that will be checked in HTTP_USER_AGENT request header.
      • page

        This node contains configurations related to Mage_Page module.
        • layouts

          The node specifies possible values in Page Layout drop-down on Product/Category/CMS Page edit page. If you want to add your own layout type it can be specified here.
          • [layout_code]

            The node name specifies unique internal page layout code.
            • label

              The node value specifies the layout page name that will be displayed in Page Layout dropdown. If you want to make this value translatable, you need to specify module and translate attributes in [layout_code] node. Module attribute should contain namespace of the module helper. Translate attribute should contain the name of a node which value should be translated.
            • template

              The node value specifies template path that will be used for themes that do not have definitions of page layouts. It is created for backward compatibility, if your theme uses layout handles for page layout types, you can leave it empty.
            • layout_handle

              The node value specifies layout handle code that will be applied on the pages where user specified custom Page Layout.
There is a lot more global configuration options and most of them defined for specific modules, so in the list above you see only the most used ones

Magento Admin Panel configurations

Click on the node name to see its description

  • adminhtml

    Admin panel scope. Usually contains translations, layout files and event observers configurations for backend. There were also definitions of menu and ACL resources for user permissions before 1.4, now all of those definitions are placed in separate adminhtml.xml file. But it still backward compatible for customizations those were created in previous versions.
    • layout

      All the layout update file for Magento back-end are placed here. The configuration reference of this node you can find in this section
      • updates

    • events

      Definition of event observers for adminhtml scope. See this section for details
  • admin

    The node for definition of back-end routers and fieldsets for Catalog dataflow functionality
    • routers

      Definition of controller routers for backend. See this section for details
    • fieldsets

      This node is used for fieldsets in dataflow. You may think that it have the same structure and purpose as fieldsets node in global scope node. But it is different. The fieldsets presented here are used for definition of attributes mapping while importing/exporting entities through Dataflow Module.
      • [fieldset_name]

        The name of fieldset in Dataflow module. Currently there is only 2 fieldsets: catalog_product_dataflow and customer_dataflow. Both of them have different attribute node properties inside so they are displayed as separate items
      • catalog_product_dataflow

        Fieldset for mapping of product attributes in dataflow
        • [field_code]

          The node name indicates the field that should be exported/imported by specific rules.
          • inventory

            If set to 1 indicates that field should be retrieved from inventory object of the product.
          • product_type

            The node children indicate product types where this field can be applied. Used only with inventory fields and required for them.
            • [type_code]

              The node name indicates product type code (simple, configurable, grouped, etc)
          • use_config

            The node value indicates that this field has additional field called with the same name and suffix ‘_use_config’. Can be used only with inventory fields. For example. manage_stock field has additional field called manage_stock_use_config that is used for indication of using configuration value instead of product one.
          • required

            The node value indicates that this field is required for fulfillment during the import.
          • ignore

            The node value indicates that this field will be ignored during the import. Usually used for system values like type_id and attribute_set_id.
          • img

            The node value indicates that this field should be processed as image path in media/import folder during the import. Usually used for media gallery attributes like image, small_image, etc.
          • to_number

            The node value indicates that this field should be processed as number during the import.
          • internal

            The node value indicates that this field shouldn’t be exported because it is used only for internal purpose. This node used only in Mage_Catalog_Model_Convert_Parser_Product::getExternalAttributes() method. For import and export used system node. You may ask me why? But this strange for me too.
          • system

            The node value indicates that this field shouldn’t be exported/imported because it is used only for internal purpose.
      • customer_dataflow

        Fieldset for mapping of customer attributes in dataflow
        • [field_code]

          The node name indicates the field that should be exported/imported by specific rules.
          • required

            The node value indicates that this field is required for fulfillment during the import.
          • ignore

            The node value indicates that this field will be ignored during the import. Usually used for system values like attribute_set_id and entity_id.
          • billing

            The node value indicates that this field is a field from default billing address of the customer and will be used to export/import. This field will have ‘billing_’ prefix in export/import file.
          • billing_mapped

            This node value indicates that this field can be fulfilled with customer information if value for it was not specified for billing address. For example if you will not specify ‘billing_firstname’ then the value of ‘firstname’ field will be used, because it used in billing address and is billing_mapped.
          • billing_required

            This node value indicates that this field is required for billing address, but it does not mean that you should specify it even if you do not want to specify billing address for customer. It is required only if you specify at least one required field for it.
          • shipping

            The same as billing node, but for shipping address
          • shipping_mapped

            The same as billing_mapped node, but for shipping address
          • shipping_required

            The same as billing_required node, but for shipping address
          • street

            This node value indicates that this field should be treated as street for shipping/billing addresses. If you have specified this node you don’t need to specify billing or shipping nodes, it is applied by default in such a case.
          • mapped

            The same as billing_mapped and shipping_mapped, but applied for the both types of an address.
    • global_search

      This node contains source models for global search in admin panel.
      • [source_model_code]

        The node name specifies unique internal source model code.
        • class

          The node value specifies a class name or model namespace that will be used for the search.
          • acl

            The node value specifies an acl resource that should be checked before performing the search by this search type.

Magento Frontend configurations

Click on the node name to see its description

  • frontend

    This node contains configurations for frontend application scope.
    • layout

      All the layout update file for Magento front-end are placed here. The configuration reference of this node you can find in this section
      • updates

    • events

      Definition of event observers for front-end scope. See this section for details
    • routers

      Definition of controller routers for front-end. See this section for details
    • secure_url

      This node contains the list of url paths those should be displayed in HTTPS mode if it is enabled for frontend in Magento configuration. If you are developing a payment gateway it is helpful for you.
      • [unique_action_code]

        The node name specifies internal unique code of the controller action, that is specified in its value.
    • product

      This node contains list of attributes that are used in product collection on the frontend. All of them will be automatically added to product lists. Flat version of catalog product also adds these attributes to store tables.
      • collection

        • attributes

    • category

      This node contains list of attributes that are used in category tree or collection on the frontend. All of them will be automatically added to category trees and collections. Flat version of catalog category also adds these attributes to store tables.
      • collection

        • attributes

Magento Cron configurations

Click on the node name to see its description

  • crontab

    This node contains configurations in cron application area.
    • events

      Definition of event observers for cron scope. See this section for details
    • jobs

      This node contains defentions of cron jobs in Magento.
      • [job_name]

        The node value specifies unique job name. It is your cron job identifier.
        • schedule

          The node value specifies your job schedule. It is specified like usual cron expression.
        • run

          The node value specifies your job callback.
        • model

          Callback consist of two parts. The first part before double colon is a model namespace path or class name, the second is a method name that should be invoked.

Can be applied to different scopes

Click on the node name to see its description

  • [area]

    Indicates configuration scope (fronend, adminhtml, etc)
    • events

      Definition of event observers definitions for different scopes are placed in this node.
      • [event_name]

        The node name is the event name for each you want to add an observer.
        • observers

          This node contains definitions of different observers for specified event
          • [unique_observer_name]

            This node name specifies unique observer name. I usually call it with namespace of my module, because my modules do not have more than one observers for an event in a particular scope. If you want to override the definition of a particular event observer, then you can specify its name in your custom module and specify your own model or method for an event. Such kind of interception of an event helpful if you do not need to override an observer model, just change observing of a particular event.
            • type

              Type of event observer. Possible values are object, model, singleton, disabled.

              • Object and model are the same and indicate that you want to instantiate a model each time when the event is dispatched.
              • Singleton indicates that the observer object will be instantiated only once, only its method will be invoked with each event dispatch.
              • Disabled type will not execute an observer, it is used to disable observers from another modules.

              By default the observer is a singleton.

            • model
              class

              Class or model namespace path that is used as event observer object.
            • method

              Method that is invoked when the event is dispatched
    • routers

      This node is used to define routers for controller actions
      • [route_name]

        The node name specifies route name that is used in Mage_Core_Model_Url::getUrl() method as first part in path variable before slash and and the first part of layout handle name for a controller action. For example ‘adminhtml/catalog/product’ uses adminhtml route name while used in getUrl method.
        • use

          The node value specifies which router to use. Currently Magento supports standard for frontend and admin for backend.
        • args

          The node children is passed as arguments for route initialization.
          • module

            Defines default module for this route, can be a class path. For example if you specify Mage_Adminhtml as module, router will search for controller with Mage_Adminhtml class prefix for the route.
          • modules

            This node used for definition of different modules for processing the same route. You can specify attributes ‘before’ and ‘after’ in children nodes to specify controller action class load check priority. For example, such a construction:

            <modules>
                 <module1 before="Mage_Adminhtml">MyName_Module1_Adminhtml</module1>
                 <module2 after="Mage_Adminhtml">MyName_Module2_Adminhtml</module1>
            </modules>
            

            means that while matching the route, router will check existence of a controller action at MyName_Module1_Adminhtml path before Mage_Adminhtml, and in MyName_Module2_Adminhtml after Mage_Adminhtml if it can not be found there.

          • frontName

            The node value is used as the route name in page urls. Thats why internal adminhtml route name have admin route name in url and can be changed in configuration.
    • translate

      All the definitions of translation csv files for Magento are placed in this node.
      • modules

        The node children contains the translation file paths for a module in current scope.
        • [Module_Name]

          The node name specifies the translation files module name.
          • files

            The node specifies path to translation files
            • [unique_file_code]

              The node name contains internal file code, the value contains file name in app/locale/YOUR_LOCALE directory. The node name can be used to override file path for the module translations.
    • layout

      This node contains layout update configurations. Each child node adds own layout file for processing in current scope.
      • updates

        • [layout_code]

          The node name specifies an unique internal layout code. This node have optional module attribute, that should be specified if you want allow admin user to control the output of your module.
          • file

            The node value specifies a layout file that should be loaded in current scope.

Conclusion

In this article I have described the general structure in main module configuration files.

In the next article I will describe the structure of system.xml and adminhtml.xml files. So keep in touch!

Ivan Chepurnyi
Magento guru / System architect
Ivan started as Magento Core developer in early 2007, since that time he already has 6 years of experience in different areas of Magento development. During all that time he developed enormous amount of modules and customizations, so now almost every dark corner in Magento functionality is investigated by him. He can’t keep that knowledge in secret, that why he's sharing it with the community and helps finding the way out of Magento complexity maze.

8 Responses to “Magento module configuration file reference”

  1. Great article, Ivan! Keep up the good work!

  2. Kartik Maniyar says:

    Hi,Ivan
    Greate article.
    this is very important for newbie but
    i want to add backend menu means that i want to add ‘HELP’ module
    only for admin panel not for frontend. if u have any idea abt this then tell me. and

    what is the argument of tag in magento config file?

  3. Thank you for this nice roundup… though I have a question regarding the global tag in config.xml file for some modules.
    Example 1 Wishlist module has this tags in the global namespace:

    <wishlist>
         <item>
            <product_attributes>
                 <visibility/>
                 <url_path/>
                 <url_key/>
             </product_attributes>
         </item>
    </wishlist>
    

    Example 2: Tag module

    <index>
        <indexer>
            <tag_summary>
                <model>tag/indexer_summary</model>
            </tag_summary>
        </indexer>
    </index>
    

    I really don’t get it where the system is making use out of these.

    • Ivan Chepurnyi says:

      1. This node in wishlist module contains attributes that will be loaded on wishlist page in the customer account.

      2. This node contains index models that will be invoked on index event firing and are presented in “System -> Index Management” as indexer line. A model has such methods like getName, getDescription for displaying in the grid. For implementation look into abstract class Mage_Index_Model_Indexer_Abstract

      • Thanks for your answer Ivan, I think I’m getting right there after looking at the core code. The way I understand this is something like:
        1. These custom configurations are only used by the Module that defines them (in this case the Wishlist).

        2. In the Wishlist module we need products and through the custom config variables we modify the “NORMAL” product collection fetched by catalog/product model with passing these 3 extra attributes to be selected too, so instead of grabbing the normal product collection we need 3 more attributes specific for the wishlist.

        3. Otherwise if for example we didn’t need these attributes, we would use the default product collection without defining extra config vars.
        I hope I am on the right road :)

  4. Greate tutorial
    Thx u

  5. Comprehensive and clear article. Thank you. What about adminhtml node. maybe we should use adminhtml.xml file to locate admin settings?

  6. In adminhtml.xml file currently localed only acl rules and backend menu. The description of the nodes in this file will be in the next article.

Trackbacks/Pingbacks

  1. Tweets that mention Magento module configuration file reference - E-commerce developers blog -- Topsy.com - [...] This post was mentioned on Twitter by Aldo Wink and Eсommerce Developers, ivanchepurnyi. ivanchepurnyi said: Magento module configuration file ...
  2. Lesetipps KW35 | Magento, RedDot, Wordpress - webguys.de - [...] tolle Arbeit haben die Autoren von ecomdev.org geleistet. Eine Übersicht über die Möglichkeiten der Magento-Modul config.xml mit (fast) allen ...
  3. E-Commerce Lesetipps am Morgen » Magento, Widerruf, Teil, Shops, Shop, Endverbraucher » ShopTrainer - [...] config.xml in Magento bearbeiten – zentraler Dreh- und Wendepunkt mit vielen Einstellungsmöglichkeiten http://www.ecomdev.org/2010/08/31/magento-module-configuration-file-reference.html [...]
  4. Türchen 10: Die Magento-Konfigurations-XML-Dateien « Magento Blog für Entwickler und eCommerce-Shops – webguys.de - [...] Magento module configuration file reference (sehr nett, zum Draufklicken für Beschreibungen): http://www.ecomdev.org/2010/08/31/magento-module-configuration-file-reference.html [...]

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>