(For more resources on e-Commerce, see here.)
The Magento theme structure
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,a group of related themes is referred to as a design package. Design packages contain 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)
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
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
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 add files within this directory to 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]/.
The skin files for a given design package and theme are subdivided into the following:
- 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:This contains the JPG, PNG, and GIF files used in the display of your site
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 (we will discuss the local.xml file later in this article). 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 a 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 features 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 umpteenth 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 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.
- 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?)
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_package/ outdoor_theme/ skin/ frontend/ default/ blank/ blue/ french/ german/ modern/ iphone/ outdoor_package/ 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_package/ outdoor_theme/ skin/ frontend/ default/ blank/ blue/ french/ german/ modern/ iphone/ outdoor_package/ 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.
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.Refer to the following screenshot:
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.
As you can see in the previous screenshot, you have the ability to assign a theme in a field called Translations. This is a very under-documented, yet creative feature of Magento, so let's tackle the discussion now.
First, the purpose of Translations is to allow you to specify a different output for various text elements of your site. With the language translation files a number of standard text labels, such as My Account, Checkout, and so on are translated into the desired language. These language files reside in your /app/locale directory and are triggered by selecting the language in the System | Configuration | General | Locale Options panel in your Magento backend. The Translations field we are specifying in the Design | Themes panel looks for a file called translation.csv, residing in your theme's locale directory.
If you have installed language files you'll also find a great number of translation.csv files under /app/locale. These are the core language files for both the frontend and backend of your installation, and are fully editable if you wish to change a particular phrase.
The default installation's translation.csv file contains one translation line:
"Keep your eyes open for our special Back to School items and save A LOT!","Keep your eyes open for our special Back to School items and save A LOT!"
Huh? Both phrases in this line, separated by a comma, are the same. But, ignore this line for now. The purpose of this file is to set out the format for which you can specify various text translations. The key here is to realize that translations do not have to be from one language to another, although that is a primary purpose when these translation.csv files are located within a language folder (for example, fr_FR).
So how can this file benefit you as the site administrator or designer? Imagine you wanted every place on the site that said "New Customers" to now say "New Shoppers". It would be a tedious process to go through every Magento file that contains the phrase "New Customers" and change it to "New Shoppers". Believe me, it's not a task you want to do more than once.
On the other hand, if you wanted to change NEW CUSTOMERS (as shown in the following screenshot) to NEW SHOPPERS, you simply add "New Customers","New Shoppers" to your translations.csv file:
Magento will automatically do the conversions for you on the fly, as shown in the following screenshot:
Using theme variants
Besides the obvious use of different themes within a package for different looks among store views, theme variants can be used to provide alternative frontend layouts based on date, such as holiday shopping season, or device, such as smartphone or tablet.
Scheduling a theme variant
It would be painful if changes that affect your public site content had to be manually turned on at the exact date and time you wished. For products, you can schedule price changes to automatically take effect between any two dates and times (you could have a one-hour sale price!) simply by adding the date/time configuration in the product detail screen.
Likewise, you can schedule changes in your stores' themes to take effect while you sleep! Using the following steps, you can schedule a theme variant based on a date:
- Go to System | Design in your Magento backend.
- Click on Add Design Change.
- Select the store view you wish to change.
- Choose from the Custom Design drop-down, the theme variant you want.
- Enter the Date From and Date To date and times, for the period of time you want the change to take effect.
- Click on Save.
I've never met a person yet that installed a theme and was ready to launch their Magento store without wanting or even needing changes to be made to the store design. It's natural, as a store needs to have its own personality, its own brand. Here, we hope to uncover many of the mysteries of how Magento controls a store's look and feel through layered components that, once you understand how they work together, will give you a tremendous ability to make your Magento store a unique, productive online retail destination.
The easiest way of changing the look and feel of your Magento store is by modifying existing stylesheets and graphic images. As we have learned, these are stored within your theme's directory in the /skin/frontend/ part of your Magento installation.
As always, I highly recommend that you make duplicates of the original theme files before making changes. Just to be safe!
Since Magento defines webpage areas using <div> tags, you can find it fairly easy to modify the style of the site by identifying the <div> tags—as well as other HTML tags such as <p>, <form>, and <input>—and editing the CSS styles that are assigned to them.
While you can view the source code of a webpage in any browser, there are better ways of identifying not only the HTML elements of a page, but the exact CSS style(s) that are controlling how that component appears. For Firefox browsers, you can install the Firebug plugin (http://getfirebug.com). For Safari and Chrome users, this functionality is included with the browser. Another great tool for Firefox users is the Webdeveloper add-on (https://addons.mozilla.org/pt-br/firefox/addon/web-developer/). These tools allow you to select an element on the page and view in another window what the styling rules are, that apply to the element. Once you know that, you can easily find the CSS style statement in the theme's CSS stylesheets and make any changes you wish.
Page layouts in Magento are managed by XML files that control how the various components on a page are to be assembled. Think of layout files as the blueprints of your site, in that they contain the instructions that direct how various content blocks and template files are combined to produce the structural blocks that define the final output.
Let's take a visual look at how structural blocks and content blocks are combined on a typical page, by analyzing a category page captured from our sample data default installation:
Now, let's look at this page, with the structural blocks (left) and content blocks (right) shown as overlays on this category page:
Structural and content blocks
The preceding screenshot on the left shows the outlines of the structural blocks. For a Magento page, they are the containers that dictate the positions of content blocks, as shown in the previous screenshot on the right. There are five primary structural blocks: header, left column, right column, content, and footer. Technically, a page can have any number of structural blocks, but these are the basic blocks used by most Magento themes.
Structural blocks are defined in the page.xml file located within the layout/ directory of a theme (for example, app/design/frontend/base/default/layout/page.xml). Default page templates, called by this file, are stored within the /template/page/ directory.
Content blocks represent the actual layout content that will appear on a web page. Where functionality contents (such as category listings, product listings, or shopping cart) appear, content blocks interpret the output into the text, graphics, and styles visible on the web page. The template files that contain the markup code for the content blocks are also stored within the /template/ directory (some HTML code, however, does come from the actual code output from the /app/code directory files).
Expertly controlling layouts
Magento newcomers, particularly designers, often feel a bit lost among the many layout and template files that comprise a Magento theme. However, with a bit of study and adherence to a few best practices, anyone can become a Magento design aficionado.
First, keep in mind the concept of the Magento fallback method we previously covered. Layouts are dictated by the most forward layer. This means that if the chosen theme lacks a needed layout or template file, Magento will look into the default directory for the design package, then into the base/default directory, where, unless you've been naughty and changed anything, Magento will at last find any missing components.
As a designer, this means that you can change layout structures and blocks by creating or editing files within your theme directory, and focus on overriding any base theme behaviors. In short, a theme has to have only those components that are different from the base design package.
I want to emphasize the enormity of this concept. When I wear my designer's hat, I don't have to replicate all of the many layout and template files when creating a theme. I only have to include those most likely few files that will define the delta or difference between the base package and my new theme.
This, more robust fallback method (when compared to previous Magento versions), has not been completely absorbed by third-party theme producers. You may find some themes that have many files that really define no difference from the base package. This practice does not conform to Magento's best practices, as the core Magento updates cannot be reflected properly in the theme files. In general, we look for themes structures—whether third-party or home-grown—to add only those files necessary to provide the differences between the default layouts and the customized design.
When looking for a file to edit for your intended change, first look into your theme directory. If the file is not there, look into the default directory within your theme's design package. If you find the file there, copy it into the same relative position within your theme directory.
Layout files control the various Magento modules, such as Sales, Customers, and Catalog, by using a layout XML file defining their structural blocks, content blocks, and functional components. You can find all of the default layout files under /app/design/frontend/base/default/layout. There were 36 layout files in addition to page.xml. Add-on extensions may add additional layout files to this list.
Now, here's where it may get just a bit complex: each layout file contains handles: groups of block definitions that generally correspond with a type of page produced by Magento. Handles can either be labeled <default>, meaning they will generally apply to all rendered pages, or they will have specific labels, such as <catalog_product_compare_index> which means they apply only to those pages on which that particular handle is called by the template file.
To get a better understanding of handles, let's dissect an example handle found in the catalog.xml file:
<block type="core/template" name="left.permanent.callout" template="callouts/left_col.phtml">
From this code snippet, we can find out quite a bit about what it does to affect your layout:
- <default> is the name of the handle. This name, which should never be changed (Magento relies on this name to process the functionality tied to it), suggests that it is used on all pages relating to the display of products.
- <reference> tells us into what structural or content block the enclosed content is to be defined. For example, <reference name="footer_links"> suggests that the output generated by the enclosed code will be placed within a block defined elsewhere as footer_links. We can use these references to modify where various elements may appear on a page, as we will explore a little later in this article.
As you look within each <reference> tag, you will find a collection of <block> and <action> tags. Let's look a bit more closely at this snippet:
<block type="core/template" name="left.permanent.callout" template="callouts/left_col.phtml">
</action><action method="setImgAlt" translate="alt" module="catalog"><alt>Our customer service is available 24/7. Call us at (555) 555-0123.</alt></action>
This particular section of code defines a block called left.permanent.callout. By enclosing the block with the <reference> tag, this file is telling Magento that this content block needs to be rendered within another block called left, which, as we learned earlier, is one of the default structural blocks. More specifically, left is the name of the left column structural block.
While it may appear to be a bit inside out, it is the <block> tag are most interested in. The <block> defines the content. The <reference> tag merely designates where the content block is to be placed. We can change the <reference> tag without affecting the output of the content block.
The <block> tag also specifies a template file, callouts/left_col.phtml, that contains the HTML and PHP code defining the visual output for this block (not all blocks have related .phtml files, though).
This is the main portion of the code contained within the left_col.phtml template file:
<div class="block block-banner">
<?php if(strtolower(substr($this->getLinkUrl(),0,4))==='http'): ?>
<a href="<?php echo $this->getLinkUrl() ?>" title="<?php echo $this->__($this->getImgAlt()) ?>">
<?php elseif($this->getLinkUrl()): ?>
<a href="<?php echo $this->getUrl($this->getLinkUrl()) ?>" title="<?php echo $this->__($this->getImgAlt()) ?>">
<?php endif; ?>
<img src="<?php echo $this->getSkinUrl($this->getImgSrc()) ?>"<?php if(!$this->getLinkUrl()): ?> title="<?php echo $this->__($this->getImgAlt()) ?>"<?php endif; ?> alt="<?php echo $this->__($this->getImgAlt()) ?>" />
<?php if($this->getLinkUrl()): ?>
<?php endif ?>
The <action> tags in the <block> tag tell Magento to perform certain actions as directed by the method attribute. In this case, we have three actions to perform:
- <action method="setImgSrc"> sets a file path called ImgSrc
- <action method="setImgAlt" translate="alt" module="catalog"> creates a text value called ImgAlt
- <action method="setLinkUrl"> creates a file path called LinkUrl
With these values created by the block, the assigned template file, left_col.phtml, can use these values to create the output (refer to the previous code snippet):
- $this->getImgSrc() uses the value called ImgSrc, which in our example is images/media/col_left_callout.jpg
- $this->getImgAlt() uses the ImgAlt value, or Our customer service is available 24/7. Call us at (555) 555-0123
- $this->getLinkUrl() uses LinkUrl, or checkout/cart as the link path to the target file
By changing the values set within the catalog.xml file, you do not have to change the template file unless you want to change the HTML layout elements to suit your needs.
Rather than changing the catalog.xml file, it's much, much better to override the original block by inserting the revised block into the local.xml file. Hang on, as we will discuss the local.xml file in the next section.
Perfect use of translations
Over the years, I've seen so many people struggle with the fact that the default Magento themes contain permanent callouts such as the one we examined previously. It's easy enough to substitute the graphic by simply replacing the default graphic, col_left_callout.jpg (located at /skin/frontend/default/default/images/media). However, Magento users who are not familiar with XML and PHP, much less the Magento architecture, find the ALT tag content difficult to change. Obviously, your store's phone number is not (555) 555-0123. Using the translate.csv file in your theme, which we discussed earlier, you could simply add a line such as: Our customer service is available 24/7. Call us at (555) 555-0123., If you have any questions, or need assistance, call us at (888) 555-9999, or whatever your actual phone number is. Keep in mind, that translations only apply if the entire text element matches the translation file: you can't simply translate the phone number without specifying the entire text portion.
The attributes for the <block> tag include:
- type: It defines the functional purpose of the block. Do not modify this.
- name: This is used by other blocks as a reference to which the block is to be assigned.
- before and after: This attribute can be used to position the block before or after other referenced blocks that will be placed within the same referenced block. before="-" and after="-" position the block at the very top or very bottom of the referenced block.
- template: This calls the template file that supplies the output functionality of the block.
- as: The name which is used by templates to call the block. For example, getChildHtml('left.permanent.callout') would include the block within the template file.
It's important to remember that like all XML tags, <block> tags must be closed. That is, the tag much either be matched with </block> or, where there are no child tags, closed with />, such as in <block name="call-out" />.
Using the reference tag to relocate blocks
In our previous example, the graphic callout defined by the left.permanent.callout block was designed to be placed within the left structural block, not by the name of the block, but rather by the <reference name="left"> tag. The block could be named just about anything; it's the reference tag that dictates into which structural block on the page the block will be rendered.
If we wanted this block to be positioned within the right structural block, we simply change the reference tag to <reference name="right">. By using reference tags, we can position our content blocks into the general areas of the page. To refine the placement, we can use the block attributes of before and after, or call the block from within a template file using the as attribute.
Customizing the local layout file
At this point, we've discussed how, by copying and modifying a few files for your theme, you can change the appearance of various blocks within your layout. With the release of Magento 1.4 and above, you have one additional tool at your disposal: the local layout file. In fact, this often-overlooked new feature is perhaps one of the most powerful layout tools in your arsenal!
By creating a file called local.xml and placing it within the /layout directory of your theme, you can alter your layout by turning off any blocks defined by the base package page.xml file. In other words, if you don't need or want the left.permanent.callout block, you can simply tell Magento to ignore it or, in Magento-ese, remove it. You can also use the local layout file to reposition blocks (as we described previously) or re-define specific handles. In short, it's a great way to make changes to your layouts without having to get deep into the various layout files we discussed earlier.
The first step is to create a local.xml file, if one doesn't already exist, and place it within the /app/design/frontend/[design package]/[design theme]/layout directory. Add the following code to this text file:
<?xml version="1.0" ?>
<!-- Put block overrides here -->
Within this small collection of code, you can add blocks and handles, as well as specialized statements. For example, to remove the callout block with which we have been working, add the following code between the <default> and </default> tags of your local.xml file:
<remove name="left.permanent.callout" />
And just like that, the callout block is no longer appearing on your site.
On the other hand, if we want to move our callout to another layout position—say, to the right column—and not remove it (the previous code would remove the block entirely from use), but rather unset it from the original position and place it in the new position, then use the following code:
<block type="core/template" name="left.permanent.callout" template="callouts/left_col.phtml">
<action method="setImgAlt" translate="alt" module="catalog"><alt>Our customer service is available 24/7. Call us at (555) 555-0123.</alt>
The scope of possibilities for using the local layout file is quite extensive. As you begin exploring the use of this file, I would offer the following advice:
- Use the <remove> tag to completely disable blocks rather than removing them from layout files. If you don't have any other use for the layout file that contains the block, then you won't even have the need to copy it from the base package into your theme.
- Use <action method="unsetChild"> to simply disable the block from the current layout, but allow it to be used in another position.
- If you want to modify a block or handle, copy it from the base package layout file and paste it into your local.xml file. Then make the changes you want to make. Again, this negates the need for replicating the layout files, and it gives you a much quicker ability to make modifications and test them to see if they are behaving as you expected.
Creating the look and feel of a new Magento store is, for those designers among us, one of the most exciting aspects of creating a new website. However, as we have seen, to give store owners the level of power and functionality that Magento affords, designers can no longer build static HTML pages, slap in a bit of PHP, and upload it to the server. With high levels of functionality come higher levels of architectural complexity.
Fortunately, the complexity of Magento is not nearly as daunting once you understand the methodologies of how pages are built, rendered, and styled. I struggled initially to fully understand this system. However, today I feel very comfortable navigating the design-related components of Magento after taking the time to understand how it all pieces together. Today, you have the added advantage of a much improved architecture, as well as this book in your hands.
Hopefully, I've also shown in most cases, if you want an extensively customized theme, you really don't have to start from scratch. By using the existing default themes, or using a third-party theme, you can do some quite extensive customizations simply by modifying a few key files.
Experiment and have fun!
In this article, we:
- Explored the Magento theme architecture, learning how the Magento fallback method works to ensure our pages always have something to show
- Covered the installation and configuration of themes into our Magento store structure
- Learned how to modify our themes by understanding the use of layouts, handles, and blocks
- Were introduced to a fairly new and very powerful tool: the local layout file
When you are ready to move on, we will begin the process of configuring your store for what it is intended: to sell.
Resources for Article:
- Making the Sale by Optimizing Product Pages using Magento 1.3 [Article]
- Creating Tax Rules in Magento [Article]
- Magento's Architecture: Part 1 [Article]