The Layers of Magento Site Design

In my work before eBay, when we designed a public web site it was all about menu structures, navigation flows, moving on to wire frames, design look-and-feel, and in our case design the information model behind the site (as we built sites driven from our text database product).

In reading up on Magento recently one thing that struck me is Magento did not have the same feel. While Magento gives you complete control over pretty well everything, the model is for the core product plus the extension modules you install to define the site structure. You can then change it if you do not like it.

This change of focus took me a little to get my head around, but is fundamental to the module architecture of Magento. Here is how I look at it now.

You have the core Magento product plus modules that you layer on top of each other to build the final site. Each module can make changes to the configuration of the site so far built up by previous modules.

A module is really just a way of bundling parts of a site together. It may include CSS and JavaScript files, HTML template files, PHP code to process form submissions, new content blocks to place on existing pages – there is a long list that I don’t want to go into here. It is normal for the contents of a module to be logically related, but nothing in Magento enforces this.

Examples of changes a module may make (see Magento Connect for real-world examples):

Change the look and feel of the site by changing the CSS and image files for the site.

Replace HTML templates of dynamic content blocks to make them consistent with the desired look-and-feel (for when changing the CSS alone is not enough).

Add new content blocks onto existing pages, such as a merchandising block (since you are looking at product X, maybe you will be interested in product Y as well).

Add new pages to the site that were not present before. For example a loyalty program registration may involve an additional page in the registration flow.

The order of loading modules is very important as modules apply changes to the state built up from previously loaded modules.

There are pros and cons of this layering approach.

Pros include a site can be assembled just by loading a set of modules. As a merchant, you can get a fair way just getting a module and loading it. (You may want to make some changes to make it into a nicely integrated and visually appearing site.) Most of the time you do not need to think about where to insert the new module functionality into your site – the module developer typically includes this with the module. You only need to change things if you don’t like what the module developer decided.

Cons include it’s a bit different to what most web developers are used to – it can take a while to get your head around. It also means the development of modules can be more complicated, as you need to think in terms of what you want to modify and how to make the change such that it is more likely to integrate nicely with all the other changes made by other modules.

Magento is very powerful in that it gives you a lot of options on how to make the above changes. But with great power comes great responsibility. The power makes it possible for the Magento ecosystem to exist. But it does require module developers to “do things right”, and knowing what is right is not always easy – or simply different for different use cases.

Once I got the idea was to give primary responsibility for site structure to module developers, while still allowing a specific site to override the defaults, the reasoning behind a lot of the Magento complexity became clearer … to me at least!

Disclaimer: I work for eBay, Magento is owned by eBay, but this post is personal opinion based on what I have read in product documentation and other public posts.