Send a brief
Menu

What is Magento Layout XML?

Magento Layout XML is the XML-based composition language Magento 2 uses to declare how UI blocks are nested into containers on every page. Each request matches one or more layout handles like catalog_product_view or cms_page_view_id_<identifier>; Magento merges XML from every module and theme into a final tree of <container> and <block> nodes, traversed during render. Six valid root nodes, merged module-then-theme, theme always wins.

Send a brief WhatsApp first
  • Lives in view/frontend/layout/<handle>.xml
  • Root nodes 6 valid: page, update, body, head, move, referenceBlock/Container
  • Merge order Module XML → theme XML wins last

Five steps from URL request to rendered HTML

Layout XML is not magic: it is a deterministic merge of XML files from every module and theme into one resolved tree. Here is what happens between request and response.

  1. 01Controller picks the layout handle for the request

    Every Magento request hits a controller action. That action declares which page layout file to load by setting one or more layout handles: strings like default, catalog_product_view, checkout_cart_index, or for CMS pages cms_page_view_id_<identifier>. The handle name is the link between the URL route and the XML file Magento will read. Page-type handles match every page of that type; page-spec handles match one specific entity; custom handles can be added by extensions.

  2. 02Magento gathers all matching XML from modules + theme

    Once the handle is known, Magento walks every enabled module and the active theme, collecting every view/frontend/layout/<handle>.xml file that matches. A typical product view request can pull XML from 20-30 modules: Magento_Catalog, Magento_Review, Magento_Wishlist, plus your own extensions and the theme override. Nothing is loaded yet, Magento just has a stack of XML fragments waiting to be merged.

  3. 03XML merger resolves overrides, removes, and moves

    The merger walks the stack in module-sequence order, with the theme always processed last so it wins. It honours remove="true" to strip a block, <move> to relocate one elsewhere in the tree, and <referenceBlock> / <referenceContainer> to inject children into parents declared upstream. Arguments and template paths declared later override earlier ones. The result is one fully-resolved layout tree for this specific request.

  4. 04Final tree is traversed; each block renders its template

    Magento walks the resolved tree top-down. For every <block> node it instantiates the PHP class declared in class="…", passes any <arguments> as constructor data, then calls toHtml() which loads the template="Module_Name::path/file.phtml" and renders it. <container> nodes just wrap children with optional HTML tags (often a <div>). Block output flows up to the parent container, which concatenates it with siblings.

  5. 05Final HTML is concatenated and cached in block_html

    The fully rendered HTML for each block is stored in the block_html cache, keyed by block name + customer group + store + currency. Subsequent requests skip the PHP and template execution entirely and pull rendered HTML straight from cache. This is why a layout XML change needs cache:clean layout block_html full_page three caches must be invalidated for new XML to take effect on a warm store.

Four scenarios where layout XML is the right tool

Use layout XML when you need to add, remove, move, or override blocks declaratively, without forking modules or copying templates.

  • Adding a new block to an existing page

    Drop a custom widget, banner, or dynamic content block into header, content, or footer without touching the parent module. Use <referenceContainer name="content"><block class="Vendor\Module\Block\Promo" name="promo.banner" template="Vendor_Module::promo.phtml"/></referenceContainer> in your module’s layout file targeting the right handle. Cleanest extension pattern in Magento: no override, no preference, just declarative composition.

  • Removing a default block from a page

    Hide a default Magento block, page title, breadcrumbs, related products, compare list, without disabling the parent module. <referenceBlock name="page.main.title" remove="true"/> drops the page title from a CMS page (used on hero-heavy landing pages where you draw your own H1). Cleaner than CSS display:none because the block never renders, never caches, never hits the DOM at all.

  • Reordering existing blocks

    Move an existing block to a different container or change its position with <move element="product.info.review" destination="product.info.main" before="product.info.price"/>. Useful when redesigning a PDP without rewriting every block: reviews above price, stock indicator under title, that kind of structural reshuffle. Works across containers, preserves the block’s arguments and template.

  • Theme overrides without touching parent modules

    Override layout in your theme by re-declaring the same handle file in app/design/frontend/<vendor>/<theme>/<Module_Name>/layout/<handle>.xml. The theme XML loads last in the merge chain, so it wins. Lets you customise any Magento or extension page from a single theme directory: no module forks, no preference classes, survives module upgrades cleanly because the parent module never knows it was overridden.

Three traps that break layout XML silently

Every layout-XML bug I have been called in to debug came from one of these three mistakes. Each one fails silently: no error, just wrong output.

  • Using dashes in handle names instead of underscores

    Magento layout handles use UNDERSCORES, not dashes: catalog_product_view not catalog-product-view, cms_page_view_id_what_is_hyva_themes not cms-page-view-id-what-is-hyva-themes. Magento does not auto-convert. If you name your file checkout-cart-index.xml instead of checkout_cart_index.xml, the file silently never loads: no error, no log entry, your changes just don’t appear. The URL slug uses dashes; the handle name uses underscores; mixing them up is the most common Magento layout mistake.

  • Re-declaring a block with the same name as the parent

    Each block name must be unique within the final merged layout tree. If you declare <block name="product.info.review"/> in your module and Magento_Review already declared one with that exact name, Magento silently keeps both: you end up with two blocks rendering, causing duplicate review widgets, layout corruption, or mysterious extra HTML. Always namespace your block names: vendor.module.block.name, or use <referenceBlock> to modify the existing block instead of re-declaring it.

  • Editing layout in pub/static/ instead of view/frontend/layout/

    New Magento developers sometimes find a layout XML file in pub/static/frontend/.../Module_Name/layout/ and edit it directly. That directory is a build artefact: it gets wiped clean on every setup:static-content:deploy run. The source of truth is app/code/Vendor/Module/view/frontend/layout/ or, for theme overrides, app/design/frontend/Vendor/theme/Module_Name/layout/. Edit source, then deploy. Treat pub/static/ as read-only build output.

Where layout XML sits in the wider Magento stack

Five neighbour concepts most readers want to look at next. Click through for the full deep-dive.

Read the explainerUnderstand DI compile

Magento Layout XML: frequently asked questions

What is the difference between layout XML and a phtml template?
Layout XML composes the page: it declares which blocks exist, what containers they live in, what order they render in, and which PHP class + template each block uses. The phtml template is the actual HTML markup that one block renders. Layout XML is structural and declarative ("here are the pieces and how they fit together"). Phtml is presentational and procedural ("here is the HTML for this one piece"). You change layout XML to add, remove, move, or reorder blocks; you change phtml to alter what a specific block looks like internally.
How do I find the layout handle for a given page?
Enable template-path hints in admin under Stores > Configuration > Advanced > Developer > Debug, then load the page with ?ENABLE_HINTS=1: Magento shows every active handle in the page source. Or run the page through the Magento_Developer toolbar (Adobe Commerce only). Or check the controller action that handles the URL: every controller declares its handles via $resultPage->addHandle() or by convention from the route. For CMS pages, the handle is always cms_page_view_id_ (underscores, not dashes).
Can I declare layout XML inside a CMS page?
Yes. Every CMS page has a Custom Layout Update field in the admin (Content > Pages > Edit > Custom Design tab). Paste a fragment like directly into that field: Magento merges it into the page-specific handle at render time. Useful for one-off page tweaks that do not justify a module deployment. The custom layout update wins over module XML for that single page only, which is exactly the right scope for marketing-led layout changes.
Why does not my layout XML change apply?
Three usual suspects. First, cache: run bin/magento cache:clean layout block_html full_page (all three, not just one). Second, wrong handle name: check for dash-vs-underscore mistakes and confirm the file is in view/frontend/layout/ not view/adminhtml/layout/. Third, wrong module sequence: if another module declares the same block with higher merge priority, your change is overridden; declare a sequence dependency in your module.xml so your XML loads last, or move the override into the theme where it always wins.
Does Hyvä still use layout XML?
Yes. Hyvä is a theme, not a layout-system replacement. It still uses the same handles (catalog_product_view, checkout_cart_index, cms_page_view_id_*), the same merge rules, the same and syntax. What Hyvä changes is what each block renders: Tailwind classes instead of Luma LESS, Alpine.js instead of KnockoutJS, but the composition layer above the templates is unchanged. Existing layout XML knowledge transfers 1:1 to Hyvä projects.
How do I debug a missing block?
Start with bin/magento dev:source-theme:deploy to ensure no static-content cache is masking a missing source file. Then enable layout-hint mode via the URL parameter ?ENABLE_HINTS=1 to see the live tree on the page. Then check three things: (1) the handle is active on this page, (2) no upstream remove="true" is dropping the block, (3) the block class actually exists and DI compile has not been skipped. Magento also logs unresolved class references to var/log/exception.log: tail that file while loading the page to catch the actual error.

Stuck on a Magento layout XML problem?

Send the page URL and the XML snippet: I will diagnose handle mismatches, merge conflicts, missing block declarations, and theme override gotchas. 24-business-hour reply with a written fix and a quote if rework is needed.

Send a briefWhatsApp