Don’t forget app/design/adminhtml/base/default folder when adding customs elements to Magento back-office

From the beginning of Magento until today (eg Community edition 1.7 and Enterprise Edition 1.12), Magento admin design folder has always been located in the app/design/adminhtml/default/default folder.

This folder contains all the required files to build adminhtml pages:

  • layouts to define adminhtml pages structure
  • templates used by theses layouts

So, If you need to provide specific back-office interfaces, where will you put them? in this app/design/adminhtml/default/default folder?

Magento page structure loading file API

Adminhtml is managed like the same loading API used in the front office; this API has been reviewed in Magento CE 14 and related Enterprises editions to load content in the following order:

  • Custom package / Custom theme folder
  • Custom package / default theme folder
  • Base package / default theme folder

I have previously explained the aim of this rule and what you can do with it

But the question is: adminhtml default default folder is: base package or custom package?

app/design/admintml/base/default as a default package folder

Yes it is. The folder app/design/admintml/default/default is not a default one, but the the default theme for the adminhtml default package; folder app/design/admintml/base/default can also exists even if it’s not embedded with magento sources.

So for sure, this is not an error to enhance this default package, but it does not respect the role of this loading api.

So it could be interesting to use app/design/adminhtml/base/default as folder for your new back-office interfaces


app/design/adminhtml/base/default folder does not exist in Magento sources but you can create it as you wish.
In a dream world, back-office updates should be managed as this:

  • Move app/design/adminhtml/default/default folder to app/design/adminhtml/base/default folder: we ensure this way that we have the default magento design for back-office
  • Use a custom package for the back-office updates of the existing interfaces
  • Provide new back-office interfaces in the adminhtml/base/default folder

Do you have already created the app/design/adminhtml/base/default folder for your own back-office interfaces or you do not take care of this case?

Some best practices to manage templates with the magento template loading API

I presented you a few days ago an introduction on how are built the Magento pages. Now we we’ll see how the templates files are loaded since Magento 1.4 with the template loading API and how we can use this loading API to reduce our work with Magento.

Reminder: how are defined the templates path in a layout file?

Templates are defined in the layout files in a couple block / template with a relative path like this:

<block type="module_identifier/class_suffix" template="relative/path/to/template/file/in/the/template/design/subfolder.phtml"/>

For example, here’s the definition of the block / template that defines the search form field available in your catalog pages:

So, how does Magento find the full path for the relative path defined in this structure?

Magento template loading API available since Magento community edition 1.4 and above (Enterprise 1.7 and above)

Since Magento 1.4.x, when a page is requested, Magento analyzes all couples block / template that compose it. Afterthat, Magento will look for the full path of the template file in the following folders:

  • 1. app/design/%context%/%design%/%theme%/template
  • 2. app/design/%context%/%design%/default/template
  • 3. app/design/%context%/base/default/template

Magento takes the first file found and use it.

What happens if the file is not found? By default, if template file is not found in these folders:

  • No output is renderering
  • A trace in log will be written if log is enabled

This loading API explains why we can define easily some temporary themes for your site like for christmas, summer, sales…: after setting up a new theme, you must only update some elements in your template in a new theme template folder

This is this loading API which allow Magento to drive some merchandising design on your website

We will now see how we can work more efficiantly whis this loading template API

Some best practices when building a new Magento design and theme

Copy paste the default theme when building your package?

When looking for the template file in the folders mentionned before, Magento runs a file_exists. Even if copy paste is the devil, when you build your package, duplicate content will avoid many file_exists when rendering your page, so it could be interesting to duplicate the base/default theme

But one of the drawback of duplicate base/default content will appear during magento upgrade: you won’t benefit of the new templates design for templates you have not overloaded: after upgrading the magento source code: do you really want to check if all template have changed? Or keep your own one and do not use the new functionnalities?

Today, I haven’t seen any limit of the file_exists loading. There are many others points to check before this performance option to make magento faster…

New functionnality in Magento: in base/default !!!!

Another common workaround in Magento project is that we can hear that it’s strictly forbidden to write in the in base/default template folder. I never understood why: if you run in multiple stores model and have specific packages defined for each store, this is the only way you have to share templates between each store. In case we do not want to write in base/default, the only way that we have to share template is to copy paste it in each package/default theme… wonderfull 🙂

Furthermore, if you want to share your module in Magento connect, this is the only way you have to avoid requiring a post configuration by copying the embedded template files in the current package folder (modules should be installed through only one click)

How organize your new templates file in your theme?

When we define a new couple block / template, we provide a relative path to define the related template to load. As a best practice, I cluster all my templates in a subfolder like %namespace%/%module%

This best practice has the following advantages:

  • When you develop your module, this is quicker to find it in the directory tree
  • If you share your module in Magento connect, this reduce the risk that other modules will have already existing templates in directory tree

Be lazy when you work with Magento templates!

I’ve made hosting for one of the biggest french bank and I liked this work: check everything is ok or be able to solve problem quickly and easily with the tools you made. Magento loading API is able to help you to provide you quick answer and easily manageable way to customize the appareance of a Magento website

Sometimes I hear that for performance issues, some people overload the Magento template loading API. It’s a shame to avoid using this model because your client won’t be able to drive the website marketing design: model is quite fine and allows you to do what you want easily without too much work. There are really many thing to do before updating this API for performance issues

Introduction to the Magento page structure: layout, block, templates, themes and packages

If you are developer or web designer, you have been face to face with the Magento page structure. This is not difficult to update design, but you must know how the Magento pages are built


Before describing the Magento page structure, I’ll explain what is a package and a theme, and how they are linked with Magento file system, and what is their interest

Definition: the Package and theme concepts

With a fresh install of Magento, all pages are ready to use. But I suppose that you want to customize the design to provide your own design, and packages and themes will help us


A package defines the global structure of your website: how they are structured: where is located your footer, …

Even if Magento comes with a default one, you should define your own package

The base package embedded in a native Magento is called (for frontend), base


A theme is a variant of your package: in december you would define a design based on christmas, or for the february 14th your marketing service would perhaps make a special version for the valentine’s day: your website will keep its structure, but some elements will be updated to provide a specific but temporary design: these updates will be made with a new theme of your website

Magento come with a default theme called default

Configure your frontend design: define the package and the theme

Frontend design is configured through the administrative admin panel available through the menu

System > Configuration > Design

Location context: different page structures for front-office, back-office and installation process

As you can see, page structure is different between front-office and back-office: Package and theme are dependant on one of the following context:

  • frontend: for all front-office available pages
  • adminhtml: for the administrative panel pages
  • install: for the pages displayed during the installation process

According to the context, it will be able to find the required elements which define your website structure

Magento design and directory tree

Design and themes are strongly linked with the package and theme specified and configuration values will help Magento to find how to load your page structure and content:

Page structure are defined in the folder : app/design/%context%/%package%/%theme%

For exemple, the folder app/design/adminhtml/base/default define the folder where to look for the files of the default pages embedded in the Magento back-office

Is package and theme folder case senstive? Yes. So be sure in unix locations to use (by convention) the lowercase

Magento page structure

Now you know where Magento will look for the required files to define how the page is built. We will see now what comprises a Magento page

Magento page structure content: the couple block / template

Homepage content on a Magento with a sample data package: some container can be identified
Category page content on a Magento with a sample data package: the same container can also be identified

As you can see on a default page structure, some elements can be found in many pages: this is each time the same “content”, the couple block / template: Each unitary element defined in layout is a couple block / template: these elements are part of the MVC (Model View Controller) “design pattern” embedded in Magento.

Each couple block/template define the unitary elements of your layout: the breadcrumb, the code pool, the product sheet price display, have specific rules managements to work, and are relatively independant of the others ones: do you need to know how code pool works to display the breadcrumb? does the footer has specific rules related to product sheet displayed? no; they are independant and do not need to know themselves

Templates manage only differents marketing output (christmas, summer, sales, ...) and technical output (html, xhtml, mobile, etc)

The block in the couple block/template: the logic

Block are PHP classes which define all the management rules for the display embedded in the couple block/template.

A block should not build output string: it must only prepare required values used in template

To display HTML, Blocks class should be an instance of Mage_Core_Block_Template

Templates: the design part in the couple block / template

Ok, you have defined your rules management in the block, now we must display the output: this is the template role. Template is a PHP file responsible for generating the content to send (often some HTML). It’ll only fetch from the block whose data it must manage, and process them in: no loading, no calc, this is only display

Templates files are located in the template subfolder of the current theme applied

Display the couple block template usage in our pages

If you want to display the couple block / template usage, you can enable the developper option in the system > configuration > developper > debug hint location (context other than global): this will highlight you which block class and templates are used with your layout

Magento Page structure is managed though layouts

Now that we know what is the content of a Magento page, we’ll see how they are arranged

Each page of a Magento is loaded with a layout: layout defines how the page will be built: this is a reference of how the page will be built: each update will update the page structure

For each theme you can define a layout, and so, update the page content. All used layouts are located in the layout subfolder of your couple package/theme design folder

Magento design folder will contain layouts and templates subfolders

Layout files are XML files. The root node of the XML file is <layout> to have the minimal following structure

<xml version="1.0' encoding="UTF-8"?>

Don’t forget roles of each elements in a page structure!

If you have something to remember from this topic is the role of each element which compose a magento page: very often we can see that roles used of each composant are not the expected one and shortcuts taken to build the page can make harder it’s maintenance

This structure is available for all versions on Magento 1.x. Magento 2 seems to update how will be organized the code content. We wait and see a stable release 🙂