Magento is built using the MVC model, this provides for clear sepperation of the logic and display. Each part of Magento is constructed as a module which adhears to this convention. When developing new modules you must also adhear to the convention.
Initially the structure can be a little hard to understand, however once over the learning hurdle it becomes very easy to add new features or override exisiting features.
At it’s simplest a module is two files, one to tell the system the module exists and one to detail the features of the module.
A module must follow a simple naming convention, of developer_moduleTitle. The developer will be your name or buisness name, the module title is the descriptive name for the module. For example a business called Acme creating a module to integrate with their dispatch system called mydispatch might create a module acme_mydispatch.
The module name is also the folder path to store all the files for the module. It is important that folder paths follow the naming conventions as paths are determined from class or module names and visa versa.
All modules exist in one of three folders, these are code\core, code\community, code\local
- core - used for all magento built in modules. Never edit this folder.
- community - used for modules downloaded from the magento community.
- local - used for your own developed code. Always place your overrides and modules in this folder.
Magento is written such that folders have a hierachy of local->community->core. Within the local folders the module is structured as developer/module. The folder structure for the example module is shown on the right.
config.xml
config.xml must exist in the etc folder. The file contains xml which tells Magento how to apply the module. This includes
- version number
- available models
- url rewrite rules
- url definitions
- helpers
The version is used by magento to determine if it should run SQL scripts to update the database for the current version. This means that upgrading the module is a case of dropping in the new files and updating the version number.
Models, url rewrites, url definitions and helpers will be explained more in future posts. Below is an example of the minimum possible XML
<config>
<modules>
<acme_mydispatch>
<version>0.1.0</version>
</acme_mydispatch>
</modules>
</config>
<strong>acme_mydispatch.xml</strong>
Magento needs to know that your module exists. This is done by creating an xml file in app/etc/modules called developer_module.xml. The xml tells magento the activation state and the code pool. In most cases activation state will be true as you want to use the module. The code pool is the code the module should use by default. generally this will be local.
Below is an example of the XML.
<?xml version="1.0"?>
<config>
<modules>
<acme_mydispatch>
<active>true</active>
<codePool>local</codePool>
</acme_mydispatch>
</modules>
</config>
Check the module is loaded
To check the module has loaded, open the Magento admin interface and browse to System/Configuration/Advanced. Expand the Disable modules output section, this lists all loaded modules. Your module should be listed and the active state match that set in your config file.
