[ Send this article ]
Your message has been sent.
How would you like to send this article:
[ Save this article ]
Save this article to your account for easy access.
This article has been saved to your account.
Go to my account
This article has been emailed to your Kindle.
Send this article
Complete the form below to send this article, Magento: Exploring Themes, to a friend (or to yourself). We will never share your details (or your friend's) with anyone. For more information, read our Privacy Policy.
by
Richard Carter | August 2011 |
Open Source
Magento is a popular open source e-commerce project. While it comes with a number of 'default' themes to change the look and feel of your store, many people both new and old to Magento struggle with even the more basic aspects of customizing Magento themes.
Magento can be a complex platform to customize, so this article by Richard Carter, author of Magento 1.4 Themes Design, will help you to explore Magento themes, including the following:
- Magento terminology
- What a Magento theme is: the elements that comprise a Magento theme
- Theme hierarchy in Magento
- Magento's Blank theme
- Installing and activating a Magento theme
| Read more about this book |
(For more resources on Magento, see here.)
Magento terminology
Before you look at Magento themes, it's beneficial to know the difference between what Magento calls interfaces and what Magento calls themes, and the distinguishing factors of websites and stores.
Magento websites and Magento stores
To add to this, the terms websites and stores have a slightly different meaning in Magento than in general and in other systems. For example, if your business is called M2, you might have three Magento stores (managed through the same installation of Magento) called:
- Blue Store
- Red Store
- Yellow Store
In this case, Magento refers to M2 as the website and the stores are Blue Store, Red Store, and Yellow Store. Each store then has one or more store views associated with it too. The simplest Magento website consists of a store and store view (usually of the same name):
A slightly more complex Magento store may just have one store view for each store. This is a useful technique if you want to manage more than one store in the same Magento installation, with each store selling different products (for example, the Blue Store sells blue products and the Yellow Store sells yellow products).
If a store were to make use of more than one Magento store view, it might be, to present customers with a bi-lingual website. For example, our Blue Store may have an English, French, and Japanese store view associated with it:
Magento interfaces
An interface consists of one or more Magento themes that comprise how your stores look and function for your customers. Interfaces can be assigned at two levels in Magento:
- At the website level
- At the store view level
If you assign an interface at the website level of your Magento installation, all stores associated with the interface inherit the interface. For example, imagine your website is known as M2 in Magento and it contains three stores called:
- Blue Store
- Red Store
- Yellow Store
If you assign an interface at the website level (that is, M2), then the subsequent stores, Blue Store, Red Store, and Yellow Store, inherit this interface:
If you assigned the interface at the store view level of Magento, then each store view can retain a different interface:
Magento packages
A Magento package typically contains a base theme, which contains all of the templates, and other files that Magento needs to run successfully, and a custom theme.
Let's take a typical example of a Magento store, M2. This may have two packages: the base package, located in the app/design/frontend/base/ directory and another package which itself consists of two themes:
The base theme is in the app/design/frontend/base/ directory. The second package contains the custom theme's default theme in the app/design/frontend/ default/ directory, which acts as a base theme within the package. The custom theme itself, which is the non-default theme, is in the app/design/frontend/our-custom- theme/default/ and app/design/frontend/our-custom-theme/custom-theme/ directories.
By default, Magento will look for a required file in the following order:
- Custom theme directory: app/design/frontend/our-custom-theme/ custom-theme/
- Custom theme's default directory: app/design/frontend/our-custom-theme/ default/
- Base directory: app/design/frontend/base/
Magento themes
A Magento theme fits in to the Magento hierarchy in a number of positions: it can act as an interface or as a store view. There's more to discover about Magento themes yet, though there are two types of Magento theme: a base theme (this was called a default theme in Magento 1.3) and a non-default theme.
Base theme
A base theme provides all conceivable files that a Magento store requires to run without error, so that non-default themes built to customize a Magento store will not cause errors if a file does not exist within it.
The base theme does not contain all of the CSS and images required to style your store, as you'll be doing this with our non-default theme.
Don't change the base package!
It is important that you do not edit any files in the base package and that you do not attempt to create a custom theme in the base package, as this will make upgrading Magento fully difficult. Make sure any custom themes you are working on are within their own design package; for example, your theme's files should be located at app/design/ frontend/your-package-name/default and skin/frontend/ your-package-name/default.
Default themes
A default theme in Magento 1.4 changes aspects of your store but does not need to include every file required by Magento as a base theme does, though it must just contain at least one file for at least one aspect of a theme (that is, locales, skins, templates, layout):
Default themes in Magento 1.3
In Magento 1.3, the default theme acted the way the base theme did in Magento 1.4, providing every file that your Magento store required to operate.
Non-default themes
A non-default theme changes aspects of a Magento store but does not need to include every file required by Magento as the base theme does; it must just contain at least one file for at least one aspect of a theme (that is, locales, skins, templates, layout):
In this way, non-default themes are similar to a default theme in Magento. Non-default themes can be used to alter your Magento store for different seasonal events such as Christmas, Easter, Eid, Passover, and other religious festivals, as well as events in your industry's corporate calendar such as annual exhibitions and conferences.
Blocks in Magento
Magento uses blocks to differentiate between the various components of its functionality, with the idea that this makes it easier for Magento developers and Magento theme designers to customize the functionality of Magento and the look and feel of Magento respectively. There are two types of blocks in Magento:
- Content blocks
- Structural blocks
Content blocks
A content block displays the generated XHTML provided by Magento for any given feature. Content blocks are used within Magento structural blocks. Examples of content blocks in Magento include the following:
- The search feature
- Product listings
- The mini cart
- Category listings
- Site navigation links
- Callouts (advertising blocks)
The following diagram illustrates how a Magento store might have content blocks positioned within its structural blocks:
Simply, content blocks are the what of a Magento theme: they define what type of content appears within any given page or view within Magento.
Structural blocks
In Magento, a structural block exists only to maintain a visual hierarchy to a page. Typical structural blocks in a Magento theme include:
- Header
- Primary area
- Left column
- Right column
- Footer
| Read more about this book |
(For more resources on Magento, see here.)
What makes a Magento theme?
A Magento theme is a collection of files that define the look, layout, and other outputs from the Magento system.
Unique aspects of a Magento theme
Magento themes differ from design implementations in other content management systems and e-commerce platforms in a few key ways:
- Maximum ability to customize Magento
- Support for multiple concurrent themes
- They offer an uninterrupted workflow
- They minimize debugging time for errors
Magento's theming system provides the ability to highly customize the way Magento looks to your customers: you can customize every aspect of your Magento store through layout, skin files (CSS and images), templates, and locale files.
The support of multiple concurrent themes is another feature which makes Magento somewhat unique in its field, allowing you to style your store differently for Magento.
Typical Magento theme file types
The files in a Magento theme can be categorized into a few categories:
- Skins
- Layouts
- Templates
- Locales
Skins
Skins are probably the easiest aspect to understand for web designers who are not familiar with Magento. A skin in Magento consists of CSS (Cascading Style Sheets), images, and any behavioral JavaScript your theme requires.
Skins are located in the /skin/frontend/interface-name/theme-name directory in Magento 1.4, where interface-name is the name of your Magento interface, and theme-name is the name of the theme within the interface.
Magento 1.3 skin directory
In Magento 1.3, a theme's skin directory was something like app/ design/frontend/default.
Layouts
Layouts define the structure of blocks for different pages in your Magento store in XML (.xml) files. A theme's layout files are located in the app/design/frontend/ interface-name/theme-name/layout/ directory (the same as Magento 1.3).
Layout files can also define meta information for pages and which character set a page should be encoded in (for example, utf-8).
Templates
Templates are used in Magento themes to generate any necessary (X)HTML mark-up for the various content blocks in your store such as the basket, category links, and product view. They use a mixture of (X)HTML and PHP and are saved as .phtml files. You will find a theme's template files in the app/design/frontend/ interface-name/theme-name/template/ directory of your Magento installation.
Locales
Locales are possibly the least-common element of Magento theming; a locale is used to customize the language of a Magento store. For example a locale might translate store elements to Spanish for a store with a Spanish store view.
Locales are stored in the app/design/frontend/interface-name/theme-name/ locale/ directory relative to where you installed Magento, which is where they were also located in Magento 1.3. Locale files are stored as plain text files such as .csv (comma-separated variable format).
Theme hierarchy in Magento: the fallback pattern
Magento has rules in place to tell it which files have precedence to be displayed if there are multiple themes active on a store.
Theme hierarchy exists in Magento to ensure that, if a file (for example, a stylesheet or a template) does not exist in a customized theme, Magento will still be able to find the file in the base theme. This is known as the fallback theme.
The base theme
Magento theme hierarchies worked differently in Magento 1.3: there was no base theme in Magento, which meant it was easy to forget to add a required file to your store's default Magento theme, potentially meaning that your store could break when viewed by visitors.
The addition of the base theme in Magento 1.4 onwards should negate this problem, so long as you build your theme correctly, creating only files you have changed to customize your new theme, and not duplicating an existing theme, as these were the common practices in Magento 1.3.
An example of theme hierarchy
Take the example of a Magento store, M2. At the very top of the hierarchy is your custom theme.
If this theme requests a file—use a stylesheet, style.css, as an example—Magento will first look in app/design/frontend/your-custom-package/your-custom-theme, and then skin/frontend/your-custom-package/your-custom-theme. If style.css can't be found in these directories, Magento will resort to the next theme in the hierarchy; your custom package's default theme. This means Magento next looks for the file in the app/design/frontend/your-custom-package/default and skin/frontend-your-custom-package/default:
If the requested file is still not found by Magento, it reverts to the base package, looking in the app/design/frontend/base/default and skin/frontend/base/ default directories. As a last resort, if the file is not found in any of these packages, Magento will respond with a rendering error, as it can't find a requested file needed to display itself.
The Blank theme
The Blank theme is particularly useful to web designers creating custom Magento themes as it strips Magento back to its basics and allows you to see the basic components of a Magento store without the fuss of a more complex theme.
(Move the mouse over the image to enlarge it.)
The Blank theme for Magento was originally available through Magento Connect but in Magento 1.4 it comes installed by default. You will find the Blank theme in the /app/design/frontend/default/blank and /skin/frontend/default/blank directory of your Magento installation.
While many designers used the Blank theme as the base of their custom Magento theme for Magento 1.3 and below, it's advisable not to do this in Magento 1.4 as it will make your theme less likely to be upgrade-proof in the future.
Installing and activating a Magento theme
One of the fundamental tasks for a Magento theme designer is to be able to install and activate a theme. Firstly, chose a theme from the Magento Connect community. For this example, you'll be using the Blank theme:
(Move the mouse over the image to enlarge it.)
The Blank theme is already installed in Magento 1.4, but provides an easy example to display package installation and activation within Magento.
If you select Get Extension Key, you will be provided with a text value that you can use in your Magento store's administration area to download the theme automatically through Magento Connect.
Installing a Magento theme
Once you have the Extension Key, log in to your Magento administration panel and navigate to System | Magento Connect | Magento Connect Manager:
(Move the mouse over the image to enlarge it.)
You may be presented with an error page after this if you have not set the correct file permissions on sub-directories in your Magento installation's root directory:
Once you've corrected this, if necessary, Refresh the page and you will be presented with the Magento Connect Manager:
Under Install New Extensions, you need to paste the extension key for the package in to the Paste extension key to install field. Finally, click on the Install button and you will see the progress displayed beneath:
(Move the mouse over the image to enlarge it.)
Your theme is now installed; next step is to activate it.
Activating a Magento theme
Once you have installed a theme through Magento Connect, it will not be visible to your visitors. To make a theme visible to your Magento store's visitors, you will need to activate it. Select System | Configuration from the Magento administration panel navigation:
On the left, select the Design option from under GENERAL:
Here, you need to tell Magento which package to display. As you've seen before, you can assign a package at two levels: website level and store view level. Set this package at website level as the example store only contains store view for this example. The first step is to define the Current Configuration Scope in the top-left of the administration panel as Main Website. This defines your store's interface in your store:
You now need to define values under the Themes section, which you may need to expand to see. It's worth noting that you need to leave the Current Package Name field as default. The remaining values—Translations, Templates, Skin (Images/ CSS), Layout, and Default to blank:
If you refresh the frontend of your Magento store now, you'll see the newly activated theme displayed:
(Move the mouse over the image to enlarge it.)
Can't see your theme?
If you can't see your new theme once activated, you may need to disable Magento's cache.
If you want to change these at the theme level of your Magento store, simply select the Default Store View or equivalent value nested under the relevant value in the Current Configuration Scope drop-down:
If you now navigate again to the Design tab, you will be able to configure the theme assigned at this level of your store in a similar manner to the interface level configuration you saw previously.
Good practice in Magento theming
There are a number of points that a good Magento theme will typically abide by:
- The use of only one layout file called local.xml, where any layout updates specific to the custom Magento theme are declared. Additionally, it is considered bad practice to create any layout files with the same name as any layout file in Magento's base theme.
- Similarly, there should be no CSS files within your theme's skin that use the same name as any CSS file in the default skin.
- Restricting any .phtml (Magento template files) to just those which have been changed for use with the custom theme.
Adhering to these guidelines of Magento theming make it easier to upgrade your Magento installation without making changes to your theme files.
Summary
You've now looked in to how a Magento theme works in theory, including the following:
- Terminology used in Magento themes
- The elements that make up a Magento theme
- What is the theme hierarchy in Magento, and how it works
- Some good practice guidelines to consider when creating a custom Magento theme
- What Magento's Blank theme is
- Installing and activating a Magento theme using Magento Connect
Further resources related to this subject:
- Integrating Twitter with Magento [article]
- Integrating Facebook with Magento [article]
- Getting Started with Magento Development [article]
About the Author :
Richard Carter
Richard Carter is a front-end web developer with a passion for integrating designs in a range of open source e-commerce and content management systems, including Magento, MediaWiki, Joomla!, and Drupal. His expertise has led clients including University College Dublin, Directgov, NHS Choices, and BusinessLink.gov.uk, to consult his knowledge on open source systems.
Richard is Creative Director at Peacock Carter Ltd (peacockcarter.co.uk), a web design and development agency based in the North East of England. He graduated from the University of Durham in Software Engineering, and currently lives in Newcastle-upon-Tyne. He blogs at earlgreyandbattenburg.co.uk and tweets at twitter.com/RichardCarter.
Post new comment