OK folks, we’re not going to rush things. Lets take this theming for Magento one step at a time. 🙂
In today’s tutorial, I’ll be discussing the architecture of Magento themes, the reason for this architecture and a brief introduction into a general idea of what goes where and why.
The installation… lets get it out of the way
The Magento installation is, essentially, a click-through process. You need to have a MySQL database created on a server, as well as the login details for this database. Other than that, the various options are fairly clear and straight forward.
For further information on installing Magento, visit the Magento Installation Guide and Knowledge Base.
Right, it’s installed. So… where do I start then?
The core idea, I believe, within the Magento theme architecture, is the complete separation of form and function (ie: design and functional code). For this reason, each theme is, first and foremost, stored in two folders- app and skin. The app folder holds all templates (consisting of *.phtml and *.xml files… I’ll explain in a bit) while the skin folder holds all images, CSS stylesheets, Javascript files, etc.
Cool. But how do I structure my theme?
First things first. It is very important that your basic folder structure is exactly the same in both the app and skin folders. The structure is divided into two levels- the “interface” and the “theme”. An interface is, essentially, a group of themes or can be seen as a folder in which your theme resides. In your interface, it is always good to make sure that at least one theme within the interface contains all necessary template files (the same applies to the skin folder interface). If you’re creating one theme for a single store, it may make sense to create your theme within the default interface (the “default” theme within this interface contains all necessary files for theming). Alternatively, simply creating a copy of the “default” theme within your custom interface would do the same thing.
To visually illustrate the concept of interfaces and themes, the folders will look something like this:
root_directory
|_app
|__default
|___default
|__your_new_interface
|___default
|___your_new_theme
|____all template files within your theme
root_directory
|_skin
|__default
|___default
|__your_new_interface
|___default
|___your_new_theme
|____all asset files within your theme
OK. My structure is set. What about those template files you mentioned earlier?
Templates are, essentially, the various areas of your Magento store. They use a combination of *.phtml files (HTML files that can execute PHP commands) and *.xml files (determine layout, declare sidebar block calls, etc) to structure and set out the content for the various sections of your Magento store.
Working with these templates is another tutorial, for now I’d like to mention one thought that helped me a lot when theming for Magento. The system is built in a completely logical manner. For example, if you wish to customise a newsletter signup block for a particular template (theoretical example) you will look in the newsletter.xml file, and not in the template file you’re wanting to customise. That’s just a mindset thing that you may have to get your head around before theming for Magento.
A quick word on falling back
Before I wrap things up, I’d like to comment on the way Magento themes fall back. By “fall back”, I’m referring to the concept of “looking” for a particular file in the current theme and, if the file doesn’t exist, falling back on a fail safe copy of the file. This is the purpose of making sure we always have a fully featured theme within our desired interface. If, for example, your theme template files require button.jpg and your existing theme doesn’t have the file, Magento will look at all other themes in your interface until it finds the file. There is a much more complex explanation for this in a slideshow presentation I read through a few months ago. The presentation is by Jonathan Lackey and can be found here. Essentially, this also means that, if we so with, we’re able to make our theme smaller and rely on existing templates from our “fully featured” theme (for example, simply modifying CSS and selected XML files instead of the entire theme).
Until next time…
I think this is where I’ll leave it this time ’round, folks. In the next tutorial, I’d like to get into a bit of actual theming (now that our architecture is in place) and touch on a few conventions that could greatly speed up the theming process, as well as a few concepts that can become quite important when theming regularly.
Leave a Reply