Magento Default System Configuration Values

Like this article? Frustrated by Magento? Then you’ll love Commerce Bug, the must have debugging extension for anyone using Magento. Whether you’re just starting out or you’re a seasoned pro, Commerce Bug will save you and your team hours everyday. Grab a copy and start working with Magento instead of against it.

This is more of an addendum to my previous articles on the System Configuration system than an entirely new article. Go back and read up if anything’s over your head.

When you create a new System Configuration path, Magento doesn’t store a default value. This is true even for the default stock system configuration. You can confirm this by looking at the core_config_data table.

mysql> select * from core_config_data ;
+-----------+---------+----------+----------------------------+------------+
| config_id | scope   | scope_id | path                       | value      |
+-----------+---------+----------+----------------------------+------------+
...

This table will only store values that have been explicitly set via the Admin Console or other programatic means.

If you request the value of a System Configuration path that doesn’t have a value explicitly set, Magento will check the global config tree for a default value. Although not required, it’s a good idea to set a default value for your custom configuration variables. It’s simple enough to do, and will ensure nothing unexpected happens when a blank value is retrieved for your config variables.

Setting up Default Values

As previously mentioned, default values are stored in the global config tree. This is slightly counter-intuitive, as one might expect the values to be stored in the same system.xml that the paths themselves are configured in. As with many things Magento, the old

Ours is not to question why, ours is but to do or die

serves as your best bet for coping with this. If that’s not good enough, try thinking of the global config as a place to store commonly used values, and system.xml as the place you configure a UI for changing those values.

Hand holding out of the way, let’s get to it.

In your module’s config.xml, add a top level section named <default/>.

<!-- File: app/code/local/Packagename/Modulename/etc/config.xml --> 
<config>
    <!-- ... -->
    <default>
    </default>
    <!-- ... -->
</config>

This is the top-level node where you’ll be storing your default values. Next, take your configuration path, and convert it into an XML tree node. For example, if you were setting up a default value for the configuration path

design/header/welcome

your config would look something like

<!-- File: app/code/local/Packagename/Modulename/etc/config.xml --> 
<config>
    <!-- ... -->
    <default>
        <design>
            <header>
                <welcome>Default welcome msg!</welcome>
            </header>
        </design>
    </default>
    <!-- ... -->
</config>

With a configuration setup like the one above, requests for

design/header/welcome

would, with no value configured, return the text “Default welcome msg!”.

This example is based on an existing configuration setting in a stock Magento install. Remember, most of Magento functionality is built using the same Module system you use to customize the system. Let’s take a look at the actual configuration of the design/header/welcome value.

<!-- File: app/code/core/Mage/Page/etc/config.xml -->
<default>
     <design>
         <head translate="default_description" module="page">
             <default_title>Magento Commerce</default_title>
             <default_description>Default Description</default_description>
             <default_keywords>Magento, Varien, E-commerce</default_keywords>
             <default_robots>*</default_robots>
             <default_media_type>text/html</default_media_type>
             <default_charset>utf-8</default_charset>
         </head>
         <header translate="welcome" module="page">
             <logo_src>images/logo.gif</logo_src>
             <logo_alt>Magento Commerce</logo_alt>
             <welcome>Default welcome msg!</welcome>
         </header>
         <footer translate="copyright" module="page">
             <copyright>&amp;copy; 2008 Magento Demo Store. All Rights Reserved.</copyright>
         </footer>
     </design>
</default>

This is the full default configuration for the

design/*

configuration hierarchy. One thing different from our previous examples is the optional translation attributes.

<header translate="welcome" module="page">

The translate and module attributes tell the system which nodes need to be translated, and which module’s Data Helper should be used to do the translating. In the above example that means the welcome node would be translated with

Mage::helper('page')->__(...);

Remember, if you call the helper factory without a second URI portion, Magento will default to the data helper.

//the same
Mage::helper('page')->__(...);
Mage::helper('page/data')->__(...);

If you wanted multiple sub-nodes to be translated, just separate the names with commas

<example translate="foo,baz,bar" module="page">

Wrapup

Short and sweet this week. While not necessary, it’s a good idea to set your System Configuration paths with default values. By setting a default early, you ensure that there will always be a logical value returned for the configuration path and not have to worry about jury rigging one in later, when a user may have inadvertently saved a value with an empty string.

Like this article? Then you’ll love Commerce Bug, the must have debugging extension for anyone using Magento. Whether you’re just starting out or you’re a seasoned pro, Commerce Bug will save you and your team hours everyday. Grab a copy and start working with Magento instead of against it.

Originally published November 28, 2010
blog comments powered by Disqus