学步园

The first step will be duplicating the default theme folder structure so that we can always turn back the changes if we damage anything. Magento’s default template structure is shown below, and there are two folders we must duplicate. Duplicating means creating a new folder with the same contents as the source folder. The simplest method is copying the folder from the original theme or duplicating it with an SSH or similar client.

Base folder structure:

Lets name the new template as new_theme. Then the new folder structure should look like this:

New folder structure:

Of course we don’t need to duplicate the whole structure. If the required file is not found in the new_theme directory it will be taken from the default theme’s directory.

After duplicating the folders we need to switch the theme from the administration area.

Step 1. Go to System > Configuration > Design via the top navigation bar Step 2. Under “Themes” and in the “Default” text field, type: new_theme Step 3. Press the “Save config” button in the upper right corner

Any external stylesheet files (css) or javascript/ajax libraries (js) that we want to include in our new project must be also copied to the proper folders.

Stylesheets Copy the files to /skin/frontend/default/new_theme/css/ folder Don’t forget to include any new css files in the styles.css file. We can do this by appending the following line as specified:

After

Javascript / AJAX libraries Create a new folder under /js/ named custom_js and copy your files to it. If you are using javascript libraries then this is also a good place to put the library files.

With the use of XML we can change almost every aspect of our new_template. For example we can set an alternate column layout for particular pages, change META information, page encoding, block types used on each page etc. There are two XML files you will be modifying in order to manage these tasks, and the two files are as follows (this info is outdated):

The new place of config.xml is:

The main file used to control values for META tags and other miscelaneous details is config.xml which is located in the /app/design/frontend/new_template/default/etc/ folder.

Below is a short description of every META tag and possible values:

This is the name of our ecommerce site. This text will appear in the browser’s title bar or the browser tab for the site. This text is also highly important for search engine keyword optimization.

This is default page header encoding so we should leave this as is.

UTF8 is a variable-length character encoding for Unicode. It is able to represent any character in the Unicode standard, yet the initial encoding of byte codes and character assignments for UTF-8 is backwards compatible with the ASCII table. For these reasons, it is steadily becoming the preferred encoding for e-mail, web pages, and other places where characters are stored or streamed.

Of course we can change it to any other encoding (ex. ISO-8859-1 or ISO-8859-2) but there is no need as long as we’re saving our files with proper UTF8 encoding.

More information about UTF8 is in the Wiki: http://en.wikipedia.org/wiki/UTF-8

The description tag controls the description meta tag and allows us to enter a short description about our site. It’s often a way to get a nice description of your page to show up in the search results if your page does rank highly in a search engine. Your best bet is to write a succinct sentence or two that uses the keyword phrases that sum up the page content.

The keywords tag controls the keyword meta tag and is the place to put the most important words that refer to the site content. Best practices suggest to enter no more than 500 characters in no more than 20 words for best results.

The robots tag controls the robots meta directive and is a simple mechanism to indicate to visiting web bots and search engine spiders if a page should be indexed, or links on the page should be followed. The content of the Robots meta tag contains directives separated by commas. The currently defined directives are index, noindex, follow and nofollow. The two index directives specify if an indexing robot should index the page or not. The two follow directives specify if a robot is to follow links on the page or not. The defaults are index and follow. The values all and none set all directives on or off: all=index,follow and none=noindex,nofollow We can simply override Magento’s default directive by placing one of the four following lines here, however it’s not recommended. The options are:

• index,follow
• noindex,follow
• index,nofollow
• noindex,nofollow

The file config.xml also contains two additional tags, not connected with any meta tags but used as a default settings for every page in our shop.

The logo_src tag sets up a reference to the logo file we wish to use on our site. The image logo.gif is located in the folder /skin/frontend/new_template/default/images/ so if we want to change it we must copy a new logo file to that folder. We can also create a new folder inside the images folder (ex. new_images) and put all our new files used by new template into it and change this tag appropriately. The easiest way to customize the logo it to simply overwrite the default logo.gif file with a new logo.gif file.

The logo_alt tag defines the alt attribute for our logo image and is mostly used by screen readers or browsers with images disabled. If one of our customers uses a screen reader or has images disabled he will see the alt text instead of image.

Using xml instead of other methods (JSON, .ini files, include / require functions) allows us to change many aspects on our page without manually changing the .phtml files. This chapter refers to our default theme so after changing the theme (as we have done above) the paths will also change.

Your core Layout is defined by page.xml which is located in /app/design/frontend/your_package/your_theme/layout/page.xml

There are two large tasks layout carries out.

First it defines the visual layout for your store. By default Magento uses a 3-column layout, so it defines use of 3columns.phtml (Located in your template/page/ folder):

If you wanted to change your store a 2-column layout, for instance, you would change the line above to reflect the .phtml you’d like to use (in this case, 2columns-left.phtml or 2columns-right.phtml).

More information about the action tag and associated methods is located in section d of this chapter.

Secondly it creates “block containers” filled with application data for output to your .phtml template files. First, if take a look at your standard 3column.phtml file you’ll see it calls the method (function) getChildHtml() a number of times:

(excerpt from 3columns.phtml - Starting at line 56):

Each of these references point towards the “block containers” defined in your page.xml and subsequent Module .xml files. You’ll notice a container for the “left” column, for the “right”, for “content”, and other standard areas. It serves up output for your .phtml template files to use. Take a look at it:

/app/design/frontend/default/default/layout/page.xml

So basically your page.xml creates Data Blocks, your .phtml Outputs that data where you want it. Hence, the names for left, right and so forth in your .phtml.

Even further, Your modules will update the available “block containers” with more specific content. For example, you’ll notice once you navigate past the front page and click a category the “Compare Box” appears. Once you click down further “The Layered Navigation” appears.

page.xml manages the layout and content blocks for all pages in your store, so all the updates you need to make to a page layout can be done from the page.xml file.

You’re aware now that page.xml contains a handle called “<default>”. The XML commands nested within the <default> layout sets up the default layout for the whole site. The subsequent handles(as listed in the top of page.xml), simply updates the default layout with the according layout for the page.

For instance, let’s say you want a wishlist everywhere in your store, but you don’t want it in the customer account pages. You’d simply locate the layout that makes up the pages, and unset the wishlist so it does not load in the account pages. Or if you want additional blocks to be called on top of the default layout, you’d assign it per handle.

If you read the code and think about whats going on it makes sense. <layoutUpdate> is UPDATING your code with new blocks. How does it know where to put the new blocks? Well remember in your default you defined “block containers” for left, right, etc. So when it says

it’s telling Magento to insert the following block into the RIGHT column when you get into “Catalog” view. (Remember, its located at layout/catalog/) so it appears once you’ve entered the catalog section of the shop. It also defines a TEMPLATE for the new block to use, so for the example above the compare box has its own template located at catalog/product/compare/sidebar.phtml (in your template folder).

As we’ve seen, the references can use different attributes for displaying blocks on our page. Possible values are:

• root - we will change it mostly to set up another .phtml file as a root template ex. (1column.phtml , 2columns-left.phtml ,2columns-right.phtml etc.)
• head - as this reffers to our <HEAD> section on page, we will use this reference name to reflect our changes in this section
• top.menu - defines our content for top menu section
• left - defines our content for left column
• right - as above but for right column
• content - defines blocks placed in main content of our page
• before_body_end - is used to add a block before end of our page so before </BODY>

There are more reference names that we could use but they are more page-specific than for global use for example:

• customer_account_navigation
• customer_account_dashboard

are used on our clients account page

product.info.additional - sets up additional block for placing related items, shipping estimator etc.

Action methods allow us to change many theme settings without appending manual changes to our .phtml files. The method listed in the method attribute refers to a method in the Model that is associated with the particular block in question. The most important methods are described below.

setTemplate

Action method setTemplate allows us to change the default .phtml file used in particular block. For example by navigating to app/design/frontend/default/default/layout/catalog/product/view.xml we can see the reference:

and by using another <template> value we are allowed to change default .phtml file used on our products page. Possible values are:

1column.phtml 2columns-left.phtml 2columns-right.phtml 3columns.phtml one-column.phtml dashboard.phtml

As we see in app/design/frontend/default/default/layout/checkout/cart.xml , there also additional 2 values for empty and non-empty cart

The method chooseTemplate is used to set a template (setCartTemplate / setEmptyTemplate) depending on quantity of items in our cart. If we have more than 0 than the

is used. If we have no items in cart then the following will be used.

The function provided by the Model is shown below:

That should clarify how we can use this particular switch. Depending on our needs we can write custom functions in our blocks and than assign a template depending on parameters returned by a function.

addCss

This method allows us to add an additional CSS file to our page on per-page basis or globally for our template. If we use a reference name “head” and action method addCss by using

then our page will have an additional line of code to attach the CSS file, for example:

As we can see, the <link> path refers to the /skin/frontend/default/default/css/ folder.

addCssIe

This method is very similar to the above but it will output a css file when a User-Agent (browser) is Internet Explorer or Maxthon. So using this method we can attach a specific css file for those browsers. This is very helpful if our page will requires changes in css dependant on a specific browser.

Usage:

Output in page source:

addJs

The above method allows us to attach a .js script in the same way as we attached a CSS file. The script path refers to the /js/varien/ folder but we can change it to suit our needs. How is that done?

Usage:

It will add a script to our page with src attribute of

addJsIe - adding a .js file to head section of page and using it if User Agent (browser) is Internet Explorer.

If we can add different css files depending on User-Agent we can do the same with our .js files. Than we can use different scripts for our IE/Maxthone users and another for other browsers.

Usage:

It will add a script to our page with src attribute of

but also inside IE comments

setContentType This method can override default headers sent by our page to the browser. So we can set a text/xml instead of text/html (or another as we wish).

Usage:

setCharset allows us to override default page encoding on per-page basis or globally. As long as we are saving our files with proper encoding this will not be necessary.

Usage:

So in this case our page will have Central European encoding instead of default UTF-8

addLink

addLink methods can be used to set a setting to which we can refer in our .phtml template files also without manually changing the .phtml files.

Example usage :

By adding a block which was found in app/design/frontend/default/default/layout/customer/account.xml into our <reference name=”content”> in app/design/frontend/default/default/layout/checkout/cart.xml we can allow the customer to skip to the account information directly from the cart.

The cart.xml file should look like below

Of course according to the previous references we can also change

in the above code to suit our needs. I’ve used for example

to show only our cart without other blocks.

As we’ve seen before, most of our xml files have a <block> tag. It defines a type of block, its name and alias “as” so we can refer to it on our page. Basic block structure looks like this:

type=”catalog/product_view_super_config” - defines the type of our block on page. This example would refer to the file /app/code/core/Mage/Catalog/Block/Product/View/Super/Config.php which defines the class Mage_Catalog_Block_Product_View_Super_Config name=”product.info.config” - defines a name for our block and should be unique as=”super_config” - defines a shortname for our block which can we use with getChild function on particular page

Blocks used in our XML files can change or override most every aspect of our design. We can use them to simply change used phtml files on per-page basis, to add additional scripts, stylesheets to our page , to move particular sections of page without needing to change phtml files.

Phtml files are template files that handle the output to browser. They are nothing more than html files with nested php tags. We use them to style our page and the look of our site.

Changing .phtml files requires basic knowledge about XHTML, CSS and understanding how to use PHP functions on a page.

Let’s have look at header.phtml placed in templates/page/html.

In this file we see basic XHTML tags, usage of CSS classes but most important - Magento functions used to get layout XML blocks and render it in our phtml file.

Mostly in our template we’ll see <? ?> tags used for functions calls. Basing on above example: <?=$this→getUrl(’‘)?> - used without parameters will return base path of our store <?=$this→getLogoSrc()?> - will render a logo image based on path used in etc/config.xml <logo_src>images/logo.gif</logo_src>

If we d’like to change our logo we can do this in two ways. First possibility is to change <logo_src> path to anything else. Second possibility is to hardcode the path directly in phtml file so

but this resolution isn’t recommended since we should use core functions and learn their usage.

<?=$this→getLogoAlt()?> - this function will allow us to change the alt tag for our logo so if it will be unavailable , the alt tag will appear. Any changes we can also append by changing <logo_alt>Magentso Commerce</logo_alt> or setting it direclty in phtml file up.

<?=__(Skip to main content)?> - all tags that look like this will be used to dynamically translate page content to other languages. We should understand it as <?=__('English text to translate')?>

<?=$this→getChildHtml(’topLeftLinks’)?> - The getChildHtml() function is the most important function used in our template. It calls particular block defined in XML file and renders it as HTML , then outputs it to the browser. We can call blocks from e