Right now we are working on upgrading all our themes to new Magento release. The good news is that all upgraded templates will be based on our new improved Magento template framework with new improved seo code. Most popular themes will be available till the end of the week. We are planning to finish upgrading all themes within 3 weeks.

Good to see they are on the case, and a three week wait is not unreasonable considering the number of templates they have made available.

Magento templates are not independent

Template providers for Magento tend to create their products using parts of the default Magento template to supplement their own code. Magento therefore uses parts of the default template, combined with the custom template, to build the site.

This method of easing template creation by not having to reproduce every last element from the default template is a cost-effective means of developing, and consequently brings the cost of each template down. But inevitably leaves developers at the mercy of the Magento developers. If they change the default template structure, it could easily break the third party templates.

This is no criticism of TemplatesMaster, this method of template creation is commonplace and quite acceptable, particularly for complex template structures such as Magento’s. But it does demonstrate how we remain at the mercy of core product developers of large, commercial products such as Magento. Their product development is commercially motivated (as it should be), but this can lead to the broader community of developers having to hop around when things change.

Magentoexpert has the solution which requires a couple of lines added to /cron.php:

Magento uses a combination of xml layout directives and php/html (.phtml) template files to build the front-end interface (storefront) of a web shop. Fundamental changes to the look and feel of the store can and should be made directly in these files, all of which reside in the directory:

/app/design/frontend/default/

Smaller scale tweaks to page content can also be added from within the admin interface. Customising the content of an individual category page, for example, is achieved through adding xml code segments to the Custom Design tab of a category.

The difficulty we found was that any customisations for an individual category were added to the page in addition to the standard category layout definitions, rather than replace them with a new, unique set of directives. Resulting, in our case, to duplicated elements on the page.

Solution 1: Create an additional template

The admin allows selection of an entirely different template for an individual category. A powerful option, that’s for sure, but hugely impractical for ongoing maintenance. Multiple templates means multiple changes to layout, phtml and possibly css files if any tweaks are required in the future.

Solution 2: Add category-specific custom code to the master layout xml file

The default category layouts are defined in /app/design/frontend/default/-your-template-/layout/catelog.xml (just look for the <catalog_category_default> element).

To add code for a specific category, all one needs to do is create a new element containing the internal ID of that category (changing XX to the category’s internal ID):

<CATEGORY_XX>

  ....

</CATEGORY_XX>

A good solution which fails only in that it becomes less portable. These xml files are designed to handle the template as a whole. Having specific category designations here mean the template can only be used for a single store with the correct category ID values.

Solution 3: Add custom xml code to the category via the Administration interface

The most practical solution, without a doubt. Here the custom code affects only the single category (and its child-categories should that be selected as an option).

However, both Solution 2 and Solution 3 must solve the problem that additional xml is added to the default xml. In our case, however, we must override the default settings to avoid duplication.

The unsetChild method

Thankfully, Magento provides a means of overriding the default elements, as defined in the layout template, to be replaced by new elements. You can see the unsetChild methods implimented in the screenshot here.

unsetChild

The method tells magento to remove whatever definitions that have already been created for the named elements. Usually, these would have been defined in the main template xml files. It does not remove the named elements themselves, so you are then free to redefine those elements as you wish.

In our case, we wanted to replace the category.products, product_list, and product_list_toolbar elements to avoid duplicating the product grid.

Once unsetChild had been called, we were free to add our customised grid definition below it.

The results are a default, 3-column, 9 product grid for most of the catalog, but a 4-column, 12 product grid for some individual category pages.

The remove method

Magento also provides the ability to entirely remove elements from the xml definition.

<remove name="xxxx" />

This completely removes the defined element, by name. Inappropriate in our case, because it does not provide the option of re-inserting a new version of the element into the page; it removes that element name entirely.