Magento Expert Forum - Improve your Magento experience

Results 1 to 15 of 15

Understanding Layout XML in Magento – Part 2

  1. #1
    Administrator david's Avatar
    Join Date
    Nov 2012
    Posts
    260
    Thanks
    22
    Thanked 40 Times in 33 Posts

    Post Understanding Layout XML in Magento – Part 2

    In the first part of this series, we discussed the basics of Layout XML elements and gave an overview of the rendering process.

    In part 2, we are going to discuss both in some more detail and present some techniques to perform more advanced layout actions out of the box.

    First, let’s explain a few terms that are frequently used in this article:

    MVC Action: MVC action is nothing but a method defined in a controller class and mapped with the requested URL. For example: when a category page is requested, the action method called is Mage_Catalog_CategoryController::viewAction().
    MVC action methods perform the backend processing for the current requested page like retrieving and storing data from/to the database.

    Layout Instance: Layout Instance is responsible for the page to be rendered. Before the page is rendered, Magento always creates a Layout Instance.

    Layout Update Instance: While the Layout Instance is responsible for page rendering, the Layout Update Instance is responsible for all the updates to be added in the page layout once the layout instance has been created. This instance contains the data of all layout handles added to the current page.

    Output Blocks: Output blocks are like normal blocks but they are directly involved with the response. When the layout is rendered, only the output blocks are rendered automatically. So it is output block’s responsibility to render its child blocks by calling a method like $this->getChildHtml(). For example, in the default theme, only the root block is an output block so at response time, only the root block is actually rendered but its phtml template calls methods like $this->getChildHtml('head') which renders its child blocks like the head block. So, output blocks are rendered automatically while other blocks are rendered if they are invoked by their parent blocks.

    Digging Deeper Into The Rendering Process

    In Magento, the rendering process is divided in two steps:

    -Initializing page layout

    - Sending response with the output from blocks.

    1. Layout Initialization

    The layout is normally initialized in an MVC Action method by calling $this->loadLayout(). The loadLayout() method accepts three optional arguments:

    $handles: This argument is either a string or array of strings. Each string is a name of layout handle. If this argument is passed, the specified handle(s) are added to the Layout Update Instance. If the argument is not passed or passed as null, the handle default is added automatically. If the argument is passed as a blank string or false, then the default handle is not added.

    $generateBlocks: This is a Boolean argument with default value of true. If it is set to false, the blocks defined in the layout XML are not instantiated.

    $generateXml: This is also a Boolean argument with default value of true. If it is set to false, Layout updates are loaded but not applied to the page. Also the argument $generateBlocks would have no effect in this case and no layout blocks are instantiated.

    The layout initialization happens as follows:

    1. Instances of the Layout and Layout Update are created.
    2. Layout handles are added according to the $handles argument if passed.
    3. Store layout handle STORE_[store_code] is added to the Layout Update Instance. For example, if code of current store is en, then layout handle STORE_en is added.
    4. Theme layout handle THEME_[area]_[package]_[layout_theme] is added to the Layout Update Instance. For example, if the page rendered is for the frontend area, the current theme package name is magebase and theme name for layout is modern, then the layout handle THEME_frontend_magebase_modern is added.
    5. Action layout handle is added to the Layout Update Instance. For example, if the page rendered is a category detail page, then Magento is executing catalog module’s category controller’s view action. So it will add an action handle catalog_category_view.
    6. All Layout XML files defined for all active modules are loaded
    7. If a layout file named local.xml exists in the current theme’s layout folder, it is loaded last
    8. Layout updates of all added layout handles from the loaded layout XML are merged
    9. Layout updates of all added layout handles from the database are merged
    10. If the $generateXML argument of loadLayout() method is passed as false, the initialization is finished.
    11. The layout update data is refined by removing all blocks and block references defined with the remove tag. (As discussed in Part 1)
    12. If $generateBlocks argument is passed as false, the initialization is finished.
    13. The instances of block classes are created according to the block definitions in the Layout XML
    14. The methods are called with specified arguments on the blocks where action tags are defined. (As discussed in Part 1)


    As a result of the rendering process, we can establish the different scope of the layout handles:

    • default layout update has global scope and applied for all pages.
    • Store layout handle is applied according to the current store.
    • Theme layout handle is according to the current theme.
    • At first, it may seem that this layout handle is not so useful because we define the layout XML within the theme. So if the theme is changed, the layout XML would also be changed. But layout XML is not only specified within a theme’s layout folder. It is also used in layout updates defined in the admin panel for CMS pages, products, categories etc., usually in the Layout Update XML field. The consequence of this is that we can target different theme layout updates from the same Layout Update XML field. This comes in handy, for example, if we enable the mobile theme detection and want to make specific layout changes on the home page depending on whether the theme rendered is the mobile or the main site theme.
    • Action layout handle is applied according to the current MVC Action being executed.


    Output Block Rendering

    After the layout is initialized, the output is normally returned by calling the $this->renderLayout() method. This method accepts one optional argument: $output. When this argument is passed with an existing block name, that block is considered as an output block and rendered automatically when the layout is rendered. Magento also considers the block as an output block when its layout XML definition contains the output attribute. For example, in the default theme, the root block is defined as:



    Here, root block is considered as an output block as its definition specifies the output attribute. The value of the output attribute defines the method called to render the block. Here root block’s toHtml method is called to render it.

    A layout should have at least one output block. Normally, the root block is the only output block in a layout but there can be multiple output blocks for a single page. In that case, the output of each output block is merged and returned in the response. Block Name and Alias
    Block name and alias differ from each other in terms of the scope. The block name is unique within the whole page that is being rendered, while the alias is unique only within the parent block.



    So when a block is referenced within any block defined in the layout or any layout handle, its name is used in that reference. But when referencing the block within its parent block, the block’s alias can also be used. The block name is normally a longer, descriptive name while the alias is a short name.

    In the example above, the ‘Add to cart’ block has the name product.info.addtocart and the alias is addtocart.

    Block ordering with after and before attributes

    As discussed in Part I, the attributes before and after can be used in the block definition to define its position in the sequence of created blocks.

    These attributes can have values that specify either the name or alias of a block.



    As in the example above, product compare sidebar block defines the before attribute with a value of cart_sidebar which refers to the cart sidebar block. This means that the product compare sidebar block will be positioned before the cart sidebar block.
    When the layout is initialized, the blocks are automatically sorted according to the before and after attributes.

    We can also specify a value of ‘-‘ for the before or after attribute in which case the block will be moved to the first or last position in the block order within its parent block.

    Non-output block rendering

    As explained earlier, the non-output blocks are child blocks of output blocks and are normally rendered with the getChildHtml() method. There are also two other methods: getChildChildHtml() and getBlockHtml() also used to render non-output blocks.

    getChildHtml()

    This method renders a child block according to the block name or alias supplied in the argument.

    The first argument is the name or alias of a child block. If supplied, it returns the output of that child block. If this argument is not supplied or passed as a blank string, it renders all the child blocks specified in the layout.

    The second argument $useCache is a Boolean which is by default true. If it is true, the block is cached if the block cache is enabled under the Caching settings in the admin panel. If it is false, the block is not cached even if block cache is enabled.

    The third argument $sorted is also a Boolean which is by default false. If it is true, the child blocks are rendered according to the sorting order defined by before and after attributes.

    getChildChildHtml()

    This method is slightly different from the getChildHtml() method. getChildHtml() renders the specified child block while getChildChildHtml() renders all child blocks of the specified block.

    For example, Block A has a child Block B and Block B has child Blocks C and D. Now inside Block A, we call:

    PHP Code:
    echo $this->getChildHtml('B'); 
    This renders the output of Block B. However, if we call:

    PHP Code:
    echo $this->getChildChildHtml('B'); 
    This renders all child blocks of B which means, Block C and D are rendered.

    The method accepts four arguments: $name, $childName, $useCache and $sorted. The last two are the same as in getChildHtml() method.

    $name argument is mandatory here which defines the parent block of which child block(s) are rendered.

    $childName argument is optional. If it is passed, only that child block of the parent block is rendered otherwise all child blocks are rendered.

    getBlockHtml()

    This method is used to render any block defined anywhere in the layout. Unlike, getChildHtml(), it doesn’t need to be called in the parent block only.

    This method accepts only one mandatory argument $name. This should be the fully qualified name of the block and not an alias.

    Product Type Handles

    There are multiple product types in Magento, i.e. Simple Products, Configurable Products, Bundle Products, Group Products etc. Normally, there are some common blocks that remain the same for any product type. For example, product image, product name, description, up-sell products block etc. But each product type may have its specific features that should be shown on the product page. For example, configurable products should display selection boxes of each configurable option; bundle products should display its bundled items etc.

    As discussed previously, layout update handles define the changes to the page layout out of the box. Magento utilizes this flexibility for handling product type specific changes on the product page.

    Like all other normal pages, when a product page is requested it adds a layout update handle according to the module, controller and action which is catalog_product_view. Additionally, it automatically detects the type of product and adds a product type specific layout update handle. The format of the layout update handle name is PRODUCT_TYPE_[product_type_code] where [product_type_code] is a system code for the product type. Product type specific blocks or layout updates can be defined under these special purpose layout handles.

    The following table shows the layout update handles loaded for built-in product types:




    [TH="bgcolor: transparent"]Product type[/TH]
    [TH="bgcolor: transparent"]Layout update handle[/TH]

























    Simple PRODUCT_TYPE_simple
    Configurable PRODUCT_TYPE_configurable
    Grouped PRODUCT_TYPE_grouped
    Virtual PRODUCT_TYPE_virtual
    Downloadable PRODUCT_TYPE_downloadable
    Bundle PRODUCT_TYPE_bundle


    To see the product type handles in action, you can study the catalog.xml file. These layout update handles are defined towards the end of the file.

    Creating Our Own Layout Handles

    In terms of reusability, we can compare layout handles in Magento with user defined functions in normal code. A user defined function may contain a snippet of code to be used in many places, so that we just need to call the function where needed instead of repeating the same code everywhere.

    Layout handles can be used in a similar way. In a page, there may be some specific layout changes which are repeated for other pages, for example, adding a block in the right sidebar, removing a block from the left sidebar, defining the root template to use 3 columns, 1 column, 2 columns with left sidebar, etc… We can create a layout handle which defines these repeating changes in one place and then we can just specify the layout update handle for any other page where we need this specific layout change.

    Let’s take a simple example. Let’s say that we need the following layout changes in more than one page:

    Remove the cart sidebar block from the right sidebar
    Insert a CMS block with identifier foo in the left sidebar
    Use the 3 column layout for the page
    We have to define a unique name for the handle that doesn’t conflict with the name any existing layout handles. In our example, we will give the layout handle the name foo_bar_handle.

    Here is the layout XML code to define this handle:

    HTML Code:
    <foo_bar_handle>
     
      <reference name="right">
        <remove name="cart_sidebar" />
      </reference>
     
      <reference name="left">
        <block type="cms/block" name="foo">
          <action method="setBlockId"><identifier>foo</identifier></action>
        </block>
      </reference>
     
      <reference name="root">
        <action method="setTemplate"><template>page/3columns.phtml</template></action>
      </reference>
     
    </foo_bar_handle>
    Now, let’s say, we need the above changes on all the product pages. So, we can call our layout handle on the product page like this:

    HTML Code:
    <catalog_product_view>
      <update handle="foo_bar_handle" />
    </catalog_product_view>
    This will update the product page with the layout changes specified in our custom layout update handle.

    To keep all our layout updates in one central place, we recommend placing them in the local.xml file.

    local.xml

    As mentioned above, Magento by default reads this file if it exists at the very end of the layout instantiation. This is a very important detail since it allows us to use this file to affect the default layout of a theme without having to change the theme’s layout XML files. That was we also keep all our custom layout changes in one place for easy reference.

    We wanted to expand on the local.xml file and usage but realized that there are already several articles and tutorials about this so we decided to point you to those in our resources section below.

    Summary

    The Architecture of Magento’s Layout XML looks complex in its internal design but it is relatively simple in usage. However, being complex internally, it also provides some advanced features to achieve maximum flexibility in design. The next article in this series will delve further into some of these techniques which can be useful in advanced theme development.

    View more threads in the same category:


  2. The Following User Says Thank You to david For This Useful Post:

    redkid (09-04-2013)

  3. #2
    New member
    Join Date
    Mar 2013
    Posts
    1
    Thanks
    2
    Thanked 1 Time in 1 Post

    Default

    Thanks for great tutorial, I got much useful knowledge.

  4. The Following User Says Thank You to redkid For This Useful Post:

    david (10-04-2013)

  5. #3
    Junior Member sgdev's Avatar
    Join Date
    Apr 2013
    Posts
    11
    Thanks
    1
    Thanked 1 Time in 1 Post

    Default

    Good help, thanks

  6. The Following User Says Thank You to sgdev For This Useful Post:

    david (10-04-2013)

  7. #4
    Junior Member rocker's Avatar
    Join Date
    Mar 2013
    Posts
    106
    Thanks
    3
    Thanked 11 Times in 9 Posts

    Default

    good to have this in my practice. Thanks

  8. #5
    Administrator david's Avatar
    Join Date
    Nov 2012
    Posts
    260
    Thanks
    22
    Thanked 40 Times in 33 Posts

    Default

    Thanks man. feel free to ask me any question

  9. #6
    Junior Member
    Join Date
    May 2013
    Posts
    25
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    You have shared a really valuable information about XML layout.

  10. #7
    Junior Member Michelle_Magestore's Avatar
    Join Date
    Jun 2013
    Posts
    47
    Thanks
    1
    Thanked 6 Times in 6 Posts

    Default

    Hi everyone!

    Magestore has published a free ebook named “How to pass Magento Certification Exam in 30 days” which is very helpful for developers who want to get Magento Certificate or have insights into Magento. This book is written based on the 10 topics announced in the Study Guide of Magento.

    How to pass Magento Certification Exam in 30 days” presents full knowledge of each topic as well as provides useful tips for developers to work with Magento. At the end of some topics, you can find questions that are designed to help revise what you have learned.
    You can download this ebook for free HERE.

  11. #8
    Administrator david's Avatar
    Join Date
    Nov 2012
    Posts
    260
    Thanks
    22
    Thanked 40 Times in 33 Posts

    Default

    Very good to know this ebook, thanks Michelle_Magestore. It 's a useful ebook for any magento developer.

  12. #9
    Junior Member ccvv's Avatar
    Join Date
    Mar 2013
    Posts
    66
    Thanks
    6
    Thanked 17 Times in 13 Posts

    Default

    it 's nice ebook. Thanks for sharing.

  13. #10
    New member DanaKuperr's Avatar
    Join Date
    Sep 2013
    Posts
    2
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    Quote Originally Posted by Michelle_Magestore View Post
    Hi everyone!

    Magestore has published a free ebook named “How to pass Magento Certification Exam in 30 days” which is very helpful for developers who want to get Magento Certificate or have insights into Magento. This book is written based on the 10 topics announced in the Study Guide of Magento.

    How to pass Magento Certification Exam in 30 days” presents full knowledge of each topic as well as provides useful tips for developers to work with Magento. At the end of some topics, you can find questions that are designed to help revise what you have learned.
    You can download this ebook for free HERE.

    Thanks for the information. I would like to try the course. Currently working with a software development company and I would be useful to know!

  14. #11
    New member
    Join Date
    Dec 2013
    Posts
    3
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    Excellent. Thanks for sharing it, it is really a great help for me.

  15. #12
    New member
    Join Date
    Mar 2014
    Location
    Victoria
    Posts
    3
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    The ‘View’ of Magento’s MVC pattern implementation is divided in two parts: Layout and Template. The template represents a HTML block while layout defines the location of the block on a web page. Magento provides ultimate flexibility and re-usability of design by layouts defined in XML. Practice Magento Programming language in this 2 esay step.
    http://www.ptiwebtech.com.au/magento-wordpress-drupal/

  16. #13
    New member
    Join Date
    Sep 2015
    Posts
    2
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    nice information.......!!!!
    http://sukere.com/services-web-development/

  17. #14
    New member
    Join Date
    Apr 2016
    Posts
    5
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    Thanks for great tutorial.
    php site | phpmysql | php development servicesl

  18. #15
    New member
    Join Date
    May 2017
    Location
    Ahmedabad
    Posts
    6
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    Its really worth tutorial, and beneficial too a lot for the developers and specially for the one working on Magento.

    Web Development Company
    Magento Developers

Similar Threads

  1. Design and layout initialization
    By rocker in forum Template, Design, HTML, CSS, Javascript
    Replies: 11
    Last Post: 18-04-2017, 07:14 AM
  2. Understanding Domain Level Metrics – Domain Rank
    By golddev in forum Magento SEO technique
    Replies: 1
    Last Post: 29-12-2016, 11:25 AM
  3. Replies: 1
    Last Post: 09-10-2015, 11:05 AM
  4. Magento Module Development - Part 2 - layout and blocks
    By rocker in forum Programming & Development
    Replies: 0
    Last Post: 22-04-2013, 07:31 AM
  5. Understanding Layout XML in Magento – Part 1
    By david in forum Programming & Development
    Replies: 0
    Last Post: 09-04-2013, 08:13 AM

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •