(For more resources on e-Commerce, see here.)
The Magento theme structure
Magento allows you to customize many store aspects at some or all of the GWS levels.
The same holds true for themes. You can specify the look and feel of your stores at the Global, Website, or Store levels (themes can be applied for individual store views relating to a store) by assigning a specific theme.
In Magento, group of related themes is referred to as a design package. Design packages contains files that control various functional elements that are common among the themes within the package. By default, Magento Community installs two design packages:
- Base package: A special package that contains all the default elements for a Magento installation (we will discuss this in more detail in a moment)
- Default package: This contains the layout elements of the default store (look and feel)
Themes within a design package contain the various elements that determine the look and feel of the site: layout files, templates, CSS, images, and JavaScript. Each design package must have at least one default theme, but can contain other theme variants. You can include any number of theme variants within a design package and use them, for example, for seasonal purposes (that is, holidays, back-to-school, and so on).
The following image shows the relationship between design packages and themes:
A design package and theme can be specified at the Global, Website or Store levels.
Most Magento users will use the same design package for a website and all descendant stores. Usually, related stores within a website business share very similar functional elements, as well as similar style features. This is not mandatory; you are free to specify a completely different design package and theme for each store view within your website hierarchy.
The Theme structure
Magento divides themes into two group of files: templating and skin. Templating files contain the HTML, PHTML, and PHP code that determines the functional aspects of the pages in your Magento website. Skin files are made of CSS, image, and JavaScript files that give your site its outward design.
Ingeniously, Magento further separates these areas by putting them into different directories of your installation:
- Templating files are stored in the app/design directory, where the extra security of this section protects the functional parts of your site design
- Skin files are stored within the skin directory (at the root level of the installation), and can be granted a
higher permission level, as these are the files that are delivered to a visitor’s browser for rendering the page
Templating hierarchy
Frontend theme template files (the files used to produce your store’s pages) are stored within three subdirectories:
- layout: It contains the XML files that contain the various core information that defines various areas of a page. These files also contain meta and encoding information.
- template: This stores the PHTML files (HTML files that contain PHP code and processed by the PHP server engine) used for constructing the visual structure of the page.
- locale: This directory has files that provide additional language translations for site elements, such as labels and messages.
Magento has a distinct path for storing templating files used for your website: app/design/frontend/[Design Package]/[Theme]/.
Skin hierarchy
The skin files for a given design package and theme are subdivided into:
- css: This stores the CSS stylesheets, and, in some cases, related image files that are called by CSS files (this is not an acceptable convention, but I have seen some designers do this)
- images: It contains the JPG, PNG, and GIF files used in the display of your site
- js: It contains the JavaScript files that are specific to a theme (JavaScript files used for core functionality are kept in the js directory at the root level)
The path for the frontend skin files is: skin/frontend/[Design Package]/[Theme]/.
The concept of theme fallback
A very important and brilliant aspect of Magento is what is called the Magento theme fallback model. Basically, this concept means that when building a page, Magento first looks to the assigned theme for a store. If the theme is missing any necessary templating or skin files, Magento then looks to the required default theme within the assigned design package. If the file is not found there, Magento finally looks into the default theme of the Base design package. For this reason, the Base design package is never to be altered or removed; it is the failsafe for your site. The following flowchart outlines the process by which Magento finds the necessary files for fulfilling a page rendering request.
This model also gives the designers some tremendous assistance. When a new theme is created, it only has to contain those elements that are different from what is provided by the Base package. For example, if all parts of a desired site design are similar to the Base theme, except for the graphic appearance of the site, a new theme can be created simply by adding new CSS and image files to the new theme (stored within the skin directory). Any new CSS files will need to be included in the local.xml file for your theme. If the design requires different layout structures, only the changed layout and template files need to be created; everything that remains the same need not be duplicated.
While previous versions of Magento were built with fallback mechanisms, only in the current versions has this become a true and complete fallback. In the earlier versions, the fallback was to the default theme within a package, not to the Base design package. Therefore, each default theme within a package had to contain all the files of the Base package. If Magento base files were updated in subsequent software versions, these changes had to be redistributed manually to each additional design package within a Magento installation. With Magento CE 1.4 and above, upgrades to the Base package automatically enhance all design packages.
If you are careful not to alter the Base design package, then future upgrades to the core functionality of Magento will not break your installation. You will have access to the new improvements based on your custom design package or theme, making your installation virtually upgrade proof. For the same reason, never install a custom theme inside the Base design package.
Default installation design packages and themes
In a new, clean Magento Community installation, you are provided with the following design packages and themes:
Depending on your needs, you could add additional custom design packages, or custom themes within the default design package:
- If you’re going to install a group of related themes, you should probably create a new design package, containing a default theme as your fallback theme
- On the other hand, if you’re using only one or two themes based on the feature of the default design package, you can install the themes within the default design package hierarchy
I like to make sure that whatever I customize can be undone, if necessary. It’s difficult for me to make changes to the core, installed files; I prefer to work on duplicate copies, preserving the originals in case I need to revert back. After re-installing Magento for the up-teenth time because I had altered too many core files, I learned the hard way!
As Magento Community installs a basic variety of good theme variants from which to start, the first thing you should do before adding or altering theme components is to duplicate the default design package files, renaming the duplicate to an appropriate name, such as a description of your installation (for example, Acme or Sports). Any changes you make within this new design package will not alter the originally installed components, thereby allowing you to revert any or all of your themes to the originals.
Your new theme hierarchy might now look like this:
When creating new packages, you also need to create new folders in the /skin directory to match your directory hierarchy in the /app/design directory.
Likewise, if you decide to use one of the installed default themes as the basis for designing a new custom theme, duplicate and rename the theme to preserve the original as your fallback.
The new Blank theme
A fairly recent default installed theme is the one called Blank. If your customization to your Magento stores is primarily one of colors and graphics, this is not a bad theme to use as a starting point. As the name implies, it has a pretty stark layout, as shown in the following screenshot. However, it does give you all the basic structures and components.
Using images and CSS styles, you can go a long way to creating a good-looking, functional website, as shown in the next screenshot for www.aviationlogs.com:
When duplicating any design package or theme, don’t forget that each of them
is defined by directories under /app/design/frontend/ and /skin/frontend/
Installing third-party themes
In most cases, Magento users, who are beginners, will explore hundreds of the available Magento themes created by third-party designers. There are many free
ones available, but most are sold by dedicated designers.
Shopping for themes
One of the great good/bad aspects of Magento is the third-party themes. The architecture of the Magento theme model gives knowledgeable theme designers
tremendous abilities to construct themes that are virtually upgrade proof, while possessing powerful enhancements. Unfortunately, not all designers have either upgraded older themes properly or created new themes fully honoring the fallback model. If the older fallback model is still used for current Magento versions, upgrades to the Base package could adversely affect your theme.
Therefore, as you review third-party themes, take time to investigate how the designer constructs their themes. Most provide some type of site demo. As you learn more about using themes, you’ll find it easier to analyze third-party themes.
Apart from a few free themes offered through the Magento website, most of them require that you install the necessary files manually, by FTP or SFTP to your server. Every third-party theme I have ever used has included some instructions on how to install the files to your server. However, allow me to offer the following helpful guidelines:
- When using FTP/SFTP to upload theme files, use the merge function so that only additional files are added to each directory, instead of replacing entire directories. If you’re not sure whether your FTP client provides merge capabilities, or not sure how to configure for merge, you will need to open each directory in the theme and upload the individual files to the corresponding directories on your server.
- If you have set your CSS and JavaScript files to merge, under System | Configuration | Developer, you should turn merging off while installing and modifying your theme.
- After uploading themes or any component files (for example, templates, CSS, or images), clear the Magento caches under System | Cache Management in your backend.
- Disable your Magento cache while you install and configure themes. While not critical, it will allow you to see changes immediately instead of having to constantly clear the Magento cache. You can disable the cache under System | Cache Management in the backend.
- If you wish to make any changes to a theme’s individual file, make a duplicate of the original file before making your changes. That way, if something goes awry, you can always re-install the duplicated original.
- If you have followed the earlier advice to duplicate the Default design package before customizing, instructions to install files within /app/design/frontend/default/ and /skin/frontend/default/ should be interpreted as /app/design/frontend/[your design package name]/ and /skin/frontend/[your design package name]/, respectively. As most of the new Magento users don’t duplicate the Default design package, it’s common for theme designers to instruct users to install new themes and files within the Default design package. (We know better, now, don’t we?)
Creating variants
Let’s assume that we have created a new design package called outdoor_package. Within this design package, we duplicate the Blank theme and call it outdoor_theme. Our new design package file hierarchy, in both /app/design/ and /skin/frontend/ might resemble the following hierarchy:
app/
design/
frontend/
default/
blank/
modern/
iphone/
outdoor_packkage/
outdoor_theme/
skin/
frontend/
default/
blank/
blue/
french/
german/
modern/
iphone/
outdoor_packkage/
outdoor_theme/
However, let’s also take one more customization step here. Since Magento separates the template structure from the skin structure—the layout from the design, so to speak—we could create variations of a theme that are simply controlled by CSS and images, by creating more than one skin. For Acme, we might want to have our English language store in a blue color scheme, but our French language store in a green color scheme. We could take the acme/skin directory and duplicate it, renaming both for the new colors:
app/
design/
frontend/
default/
blank/
modern/
iphone/
outdoor_packkage/
outdoor_theme/
skin/
frontend/
default/
blank/
blue/
french/
german/
modern/
iphone/
outdoor_packkage/
outdoor_blue/
outdoor_green/
Before we continue, let’s go over something which is especially relevant to what we just created.
For our outdoor theme, we created two skin variants: blue and green. However, what if the difference between the two is only one or two files? If we make changes to other files that would affect both color schemes, but which are otherwise the same for both, this would create more work to keep both color variations in sync, right?
Remember, with the Magento fallback method, if your site calls on a file, it first looks into the assigned theme, then the default theme within the same design package, and, finally, within the Base design package. Therefore, in this example, you could use the default skin, under /skin/frontend/outdoor_package/default/ to contain all files common to both blue and green. Only include those files that will forever remain different to each of them within their respective skin directories.
Assigning themes
As mentioned earlier, you can assign design packages and themes at any level of the GWS hierarchy. As with any configuration, the choice depends on the level you wish to assign control. Global configurations affect the entire Magento installation. Website level choices set the default for all subordinant store views, which can also have their own theme specifics, if desired.
Let’s walk through the process of assigning custom design package and themes. For the sake of this exercise, let’s continue with our Outdoor theme, as described earlier.
We’re going to now assign our Outdoor theme to a Outdoor website and store views. Our first task is to assign the design package and theme to the website as the default for all subordinant store views:
- Go to System | Configuration | General | Design in your Magento backend.
- In the Current Configuration Scope drop-down menu, choose Outdoor Products.
- As shown in the following screenshot, enter the name of your design package, template, layout, and skin. You will have to uncheck the boxes labeled Use Default beside each field you wish to use.
- Click on the Save Config button.
The reason you enter default in the fields, as shown in the previous screenshot, is to provide the fallback protection I described earlier. Magento needs to know where to look for any files that may be missing from your theme files.
