CustomModules

Modules are the core of Magento. Every action on the site, frontend or backend,
goes through a module. Modules act as containers for one or more of the following:
settings, database schemas, rendering objects, utility helpers, data models, or
action controllers. A module can be made of all six of these things, or just one.
Modules are defined as being on or off in an XML configuration system located in
app/etc/modules/. Each module can specify its own settings in an XML file as well,
located under themodule’s etc/ directory.
Since everything in Magento is a module, and modules have self-contained configuration
and database settings, this allows you, as a developer, to extend Magento
exactly as the core system is built.

Module Structure:

·       Module and   Default Directories

All models exist under a package directory. The package serves no purpose other 

than to allow for consistent naming of classes. All Magento modules are part of the 

Mage package. Thus, all Magento class names begin with Mage_. It is an acceptable 

practice to create a new package for your custom modules that has the name of your 

company or  rganization instead of Mage. There is no functional detriment when not 

using Mage as your package.

  - Mage/

|- Catalog/

    | |- Block/

    | |- Helper/

     | |- Model/

     | |- controllers/

     | |- etc/

     | - sql/ 

Folder structure

Every View used in our application has separate folders and subfolders to store template files. Let’s have a look at the folder structure:

• callouts - folder where are files for our callouts and ads are placed
• catalog - folder to store files used on our category, layered navigation, product, comparision pages
• catalogsearch - here we find files that are used to skin our search engine and result pages
• checkout - all the pages utilised during checkout and shopping in our shop. Here we’ll also find the shopping cart templates  

and blocks for cross-selling and coupons.

• cms - folder for static pages templates.
• core - folder containing store-switching templates (not yet active)
• customer - all customer pages (ex. account dashboard, address forms, orders list and reviews)
• datafeed - folder to store our csv, txt, xml files, used for comparision engines and other externalapplications
• directory - here we find currency switcher for our shop

• email - here we’ll find all pages that require email transport so for example order, password recovery, newsletter signup

• install - template files for Magento’s installer
• newsletter - subscribe.phtml placed in this folder will allow us to change the look of newsletter signup box on our page
• page - the most important folder in which we’ll find all main files used to style our site. More about it will be described in
following subchapter.
• payment - templates used to style our payment forms (ex. CC payment.)
• poll - 2 files to change the look of our poll depending on state (didn’t vote yet / show result)
• rating - rating block used on our products pages
• review - all files used to render the blocks used by reviews
• sales - pages for order details, invoices, recent orders
• searchlucene - result output for Zend_Lucene controller used in Magento
• tag - product tags templates are stored here

• wishlist - template files to handle the output of our wishlist actions.

·       Configuration Files:  Config.xml

Module configuration files are found in the etc folder under a module’s main directory. There are 3 different config files available, all of which are XML. The only config file that directly affects your module’s behavior is config.xml. The other two, system.xml and convert.xml, automatically create some setting forms for you on the system’smain backend configuration page. The contents of allmodules’ config files are merged into one massive collection of settings. This means that you can override the settings of any module in any other module simply by putting in the correct XML tags. This is the essence of overriding in Magento.


You can create any class for any purpose, and to install it into the system you create a new config.xml that specifies your class name in the same spot where the original class was defined.


This is also why you will see method calls like getModel(’catalog/product’) used throughout the system instead of a more simple approach like: new Catalog_Model_Product().


The use of “tags”, or names, for each class gives you a powerful way to override any
part of the system.

·       Template Changes and Template Files 


The template system in Magento is pretty controversial. The choice of using regular PHPfor the templating language has caught some criticism froma fewusers. But, the choice of regular PHPhas notmade the templating system simple or under-powered, not by a long shot. This has to be the most flexible and advanced templating system that this author has ever seen (in PHP).

A complete page is rendered as a nested set of template files (technically, a nested set of Blocks). There are no explicit “widgets” in the system, that means, you won’t find a specific “Form” class nor “Button” class or object. The lowly Block classes straddle the line between widgets and templates. The nested set of templates and blocks is controlled by... you guessed it, an XML file, specifically a set of XML files.

This is quite powerful for developers and plug-in contributors, but it seems that it is  overly complicated for most designers (even those familiar with PHP et al.).


There’s not much to say about the template files, they are simply plain PHP + HTML f

iles that end in .phtml extension. The syntax used in these files tries to use the templating 

language features of PHP’s syntax. You will see PHP’s alternate loop structure  

syntax, which utilizes the colon (:) and endwhile, endfor, and endif, a lot in these  

files. Until recently, short tags were used throughout the template files, but all these 

have now been expanded to full PHP open tags plus the word echo where appropriate. 

The structure of the directories mimics the structure of the corresponding modules, 

but it does not have to. This author has found that, when building your own 

custom modules, it is much easier to manage the files if you break convention and

·       Layout Changes.

The layout files control the structure of any final page rendering. They are located in the layout folder under your design theme. There are a number of XML files whose names loosely relate to an individual module, but they are all lower-case letters, whereas the module names traditionally use the so-called camel-case method. The most important XML file is page.xml.

app/design/frontend/default/default/layout/

...

page.xml

catalogsearch.xml

catalog.xml

checkout.xml

cms.xml

contacts.xml

The page.xml file specifies the default page structure. All modifications from any of the other XML files are modifications of settings under the default XML tag. The following is a list of tags that are common to all layout files.

   layout

• default

• reference
• block
• action
• update


Sometimes you will see tags like the following. These tags are layout handles, they behave like the default tag, but only during certain requests. These tags follow a  pattern that relates to the module, controller, and action of the given Web request. If the tag only has two parts, separated by an underscore, like cms_page, then these settings are applied to all requests to that module and controller.



  cms_page
• cms_index_defaultindex
• cms_index_defaultnoroute
• customer_account_index
• tag_customer_view
• catalog_product_view

Create your first module:  

• Start by using the “Magento module creator”. http://www.magentocommerce.com/magento-connect/modulecreator.html
• This will create a basic skeleton of a module for you. Play  with it!
• Important:

• Model: create your own and instantiate it from anywhere 
• Controller: create your actions and do some tests
• Helper: instantiate it and see what you can do, not only playing with i18n
• Sql upgrade scripts: you are able to interact with the DB as your module gets upgraded.
• Blocks: see what you can do, and test the cache capabilities