When customising the functionality of Magento you should always write it as it own extension unless you have a good reason not to. The behaviour of Magento extensions relies to a huge degree on a range of different xml files. In this series I will explain which xml file does what.
The very first thing when starting with your own extension is to tell Magento exactly that. All that is needed is for you to place a new xml file in app/etc/modules/. By convention you should name it NameSpace_ModuleName.xml. Below is an example
<?xml version="1.0"?>
<config>
<modules>
<NameSpace_ModuleName>
<active>true</active>
<codePool>community</codePool>
</NameSpace_ModuleName>
</modules>
</config>
There are two decisions you need to make when writing NameSpace_ModuleName.xml. The first is where to put it – the codepool.
The possible options for codePool are core,community and local and correspond to the folders under app/code. The order in which Magento loads is first from core, then community and lastly from local.
And the second decision is how to name it. The naming corresponds to the folder structure Magento expects. In most cases you can read the underscore (_) as contains folder.
So for our extension we need to create a folder NameSpace and subfolder ModuleName.
Congratulations you have written your first extension. You can verify that it is working by going into the Magento back-end System > Configuration > Advanced and you will see NameSpace_ModuleName listed under Disable modules output.
Tip:
You can turn off an extension completely by changing
<active>true</active>
to
<active>false</active>
This works for all extensions. See also this related quick tip.
Tip:
Magento is very particular about naming. Unfortunately it is not well documented and a lot is translated/converted on the fly. My advice for your first extensions is to keep it simple and name everything lowercase or capitalized. Furthermore keep everything to one word. So instead of using NameSpace just use Name or Namespace. Instead of creating grand_total just use grandtotal.
Keeping with this tip your file naming is consistently:
All folder and .php files are capitalized rest lowercase
Magento convention is to keep all system.xml, config.xml and all .phtml completely lowercase
Once Magento knows about our extension we need to tell it what to do with it. This is where the next xml file the config.xml comes in which I will start taking apart in a next post.
Originally published on magebase.com. Copyright © 2010 Magebase - All Rights Reserved.
Proud members of the 
All good advice, in particular the advice to avoid CamelCasing in class names. PHP has case insensitive classnames but the files Magento will be autoloading will most likely not being case insensitive. That one killed an hour or so.
You might want to checkout Configlint. It’s an open source/free project that’s aimed at providing a set of rules to validate Magento’s config files
http://github.com/astorm/Configlint
Hi Alan,
thanks for the comment and the link. Looks like a great tool to cut down on those hard to track errors.
One further idea for your tool is to use lib/Varien/Autoload.php->autoload() and compare it with the output of your routine. Great to catch for example the compilation module still returning an old version of a class.
Cheers
Kristof
Good tip, although there’s no way (that I know of) to override the autoloader without replacing the entire class the local hierarchy. That works well for local development, but I’d be wary of replacing that file in something that I was distributing.
I have just sent you a patch with my idea. The extended autoloader is only used with-in the context of the Configlint extension.
You’re right, code is a lot better than words sometimes. I just pushed a branch with your ideas broken out into a new lint module. Anyone interested just drop by the link mentioned above.