0

Are there any articles or is there someone who can explain how Magento's layout system works. How the rendering is done, where do all these blocks come from and based on what are they placed on the page etc.

This topic seems quite big and difficult to understand at first.

EDIT:

For Magento 1.9.x

closed as too broad by Siarhey Uchukhlebau, sv3n, Fabian Schmengler, Amit Bera, Moose Jun 30 '17 at 6:13

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

2

Rendering:

The process is:

  • Mage_Core_Block_Template::_toHtml() calls renderView if the block has a template.
  • renderView() basically is the method to render the HTML, but it assumes that a template exists. It finds the full path to the template according to theme fallback rules and then calls fetchView($fileName)
  • fetchView($fileName) in turn contains the actual rendering, given a path to a template file. It adds template hints if configured, extracts assigned variables (a feature that probably nobody uses) and includes the template. Then it returns the rendered output, or directly echoes it, if the layout has been configured with setDirectOutput(true) (usually not the case).

renderView() and fetchView() are not really meant to be used directly, although Magento itself does it in a few edge cases. Take these as an example:

Core examples:

  • fetchView() can be used to render the same block but with a different template. This is used in \Mage_Adminhtml_Block_Customer_Edit_Tab_Cart::getGridParentHtml(). But I would not say that it's a particularly good example. Usually you'll want to create a new block instance to render something else.
  • renderView() is used in Mage_Usa_Block_Adminhtml_Dhl_Unitofmeasure::_getElementHtml() because the block doubles as form element renderer (implements \Varien_Data_Form_Element_Renderer_Interface) and as such can be rendered outside of the layout. Using toHtml() would have added unwanted overhead and _toHtml() would have worked, but they probably preferred using a public method.

XML Exemple:

<block type="core/template" name="name.block" as="cus.block" template="custom.custom.phtml"/>

Type:

Here the block type that refer this block is : core/template is located in: app/code/core/Mage/Core/Block/Template.php.

Name:

name="name.block" we use it when we call the block somewhere like: <?php echo $this->getBlockHtml('name.block')?>.

As:

as="cus.block" is the alias, we can use it for exemple for calling removing like: <?php echo $this->getChildHtml('cus.block')?>, remove name="cus.block".

Template:

This is the path to your custom.phtml.

We can also add ather parameters to the block like: ifconfig, after, before, output, ...

Nb: getChildHtml(): call the alias first else he call the name.

getBlockHtml() call just the name.

Merging:

How the Magento layout merge works ?

1. When loading a theme, Magento reads the configuration of all the available modules, and checks which layout files should be loaded.

2. For each file, Magento tries to load it from your theme.
If it exists in your theme, it loads it and goes directly to step 4.

3. If the file doesn't exist in your theme, it tries to load it from the base/default theme.

4. Magento parses the XML files and merges them into one.

5. Magento looks for a local.xml file in your theme, and appends whatever is there, to the previously merged layout handles.

local.xml vs module.xml:

The benefits to use local.xml :

  1. Only one file to manage overrides and updates
  2. No need to have any other .xml file for your theme since it’s dependent on the xml files inside the base folder
  3. Every change to the local.xml file is evident so there is no need to search for changes inside xml files

The drawbacks:

None that I could think of, unless transparency and evident code changes aren’t your thing.

The use:

All you have to do is to create one inside your theme’s folder and write your xml. Since magento reads through the xml files it will first search for the changes inside your newly created local.xml and apply overrides and updates and then fall through the .xml files inside the base folder if that is the default xml folder set via the magento administration.

  • Nice one. Just as a note/question ... extension related layout updates should be part of module.xml. Not? And then, if neccessary they can be modified via local.xml. – sv3n Jun 29 '17 at 11:18
  • Yes, exact..... – PЯINCƏ Jun 29 '17 at 11:22

Not the answer you're looking for? Browse other questions tagged or ask your own question.