[{"data":1,"prerenderedAt":36},["ShallowReactive",2],{"2ASJMwbw5n":3},{"id":4,"slug":5,"title":6,"excerpt":7,"meta_title":8,"meta_description":9,"page_content":10,"featured_image":26,"fields":27,"tags":29,"published":32,"published_at":33,"created_at":34,"updated_at":35},"48743686-210e-4b5b-9239-2b6f344c9987","notes/customising-the-luma-theme-header-footer-menu-checkout","Customising the Luma Theme: Header, Footer, Menu and Checkout","The practical half of Magento theme work: moving the Luma header around with layout XML, rebuilding the footer, swapping the menu for a mega menu, and tidying the checkout, with the theme-or-module call made at each step.","Customising the Magento Luma Theme, Header to Checkout","Moving the Luma header with layout XML, rebuilding the footer, swapping in a mega menu and tidying the checkout, with the theme-or-module call made each time.",{"blocks":11},[12,20],{"id":13,"data":14,"type":19},"518a8e90-f6a0-4fa0-b13a-f4ebd44ccd45",{"url":15,"title":16,"provider":17,"subtitle":18},"https://www.youtube.com/watch?v=FZCEjXWutaM","Customise the Luma header - front end theme development - Magento 2","youtube","The original video this piece is based on.","video",{"id":21,"data":22,"type":25},"c7fc25c5-1d54-40db-ae3e-c8d7980a5b9a",{"content":23,"maxWidth":24},"\u003Cp>This is rewritten from a run of videos I recorded through 2021, working live through a real Magento 2 Luma build, header then footer then menu then checkout. I have pulled the lot into one piece because the specific class names and snippets have aged, but the method has not. I have since moved most of my front end work to headless, so read this as how I customised Luma properly when Magento was the right call, not as a nudge to start a new project this way in 2026.\u003C/p>\n\u003Cp>If you have not set up the theme itself yet, start with the companion piece on \u003Ca href=\"/notes/magento-theme-development-from-scratch\">Magento theme development from scratch\u003C/a>, which covers the child theme, config-driven assignment and the build pipeline. This one assumes that exists and gets into the actual customising.\u003C/p>\n\u003Ch2>The header: move blocks, do not rebuild them\u003C/h2>\n\u003Cp>Almost all of the header is already there in Luma as blocks. The logo, the search, the mini cart, the account links all exist. So the job is not to write a new header, it is to move the existing pieces into the layout the design wants. You do that with a \u003Cstrong>default.xml\u003C/strong> in your theme, referencing the containers you want and using move instructions.\u003C/p>\n\u003Cp>There is one rule that will save you a wasted afternoon: do not override or remove \u003Cstrong>header.container\u003C/strong>. The mini cart anchors its KnockoutJS to that container, and if you replace it you will break the cart and then spend an hour putting it back. Reference it, add your own child containers inside it, and move the core blocks into those. Leave the container itself alone.\u003C/p>\n\u003Cp>The moves themselves are simple. You target a block by its \u003Cstrong>name\u003C/strong>, not its label, and the destination is also a name. Position is optional, and the hyphen shorthand for before or after means before everything or after everything, so you only get specific when two blocks land in the same place. Want the logo centred, search on the left, cart on the right? That is three move lines once your empty containers exist.\u003C/p>\n\u003Ch2>Moving a Luma block versus creating your own\u003C/h2>\n\u003Cp>Sooner or later the design wants something Luma does not have, a call to action in the header, a custom account link, a promo strip. That is a custom block, and the trick is unremarkable once you know it. The default class \u003Cstrong>Magento\\Framework\\View\\Element\\Template\u003C/strong> is as good as no class at all, Magento just needs something there, and your template path is relative to the module, so a header template sits under \u003Cstrong>html/header\u003C/strong> alongside the core ones. Moving an existing block and adding a new one are the same shape of instruction, the only difference is whether the block already existed.\u003C/p>\n\u003Ch2>The footer: clear it out and rebuild\u003C/h2>\n\u003Cp>The header earns its caution. The footer does not. There is very little in the Luma footer worth keeping, so I tended to remove the lot and rebuild. The block to know is \u003Cstrong>footer_links\u003C/strong>, which is what scatters those default link lists across the footer, and they come from a few different modules, catalog search, CMS and others, so the privacy and cookie links live somewhere different from the rest. Remove that one block and they all go.\u003C/p>\n\u003Cp>For the rebuild I leaned on small modules with Page Builder static blocks rather than hard-coding everything in the theme. A newsletter block lifted up to sit above the footer as a feature, a social row, a base footer with payment logos and the copyright line. The reason it is a module and not theme markup is that the client should be able to edit the copy and swap the icons without me, and a static block installed through an upgrade data script gives them that. It also travels: I reused the same footer modules across projects by changing the references to the new vendor folder, which is the whole argument for doing it as a module. One small thing that paid off was keeping a \u003Cstrong>media/web\u003C/strong> folder for developer-controlled assets like logos and icons, synced through the repo while the rest of media stayed git-ignored, so the foundational images shipped with the build instead of depending on someone uploading the right file.\u003C/p>\n\u003Ch2>The menu: a mega menu as a module\u003C/h2>\n\u003Cp>Replacing the Luma drop-down with a mega menu is where I always reached for a module rather than the theme. The module removes the default \u003Cstrong>nav.sections\u003C/strong> and adds the mega menu to \u003Cstrong>page.top\u003C/strong>, which is the strip just below the header rather than the header itself. Inside, it pulls the top level categories and walks down the tree, and I capped it at three levels because past that a customer cannot navigate it anyway. A mega menu in its simplest form is just a panel that overlays and holds more than a cascading drop-down, which suits a big catalogue.\u003C/p>\n\u003Cp>The one opinion I will push here: keep the menu CSS in your theme, not in the module. Magento nudges you toward LESS inside a module, and if you let every module carry its own styles you end up with SCSS scattered across ten places by the end of a project. I want all my styling compiled from one place, so the module ships behaviour and markup, and the theme styles it.\u003C/p>\n\u003Ch2>The checkout: leave it distractionless\u003C/h2>\n\u003Cp>Magento's checkout is deliberately stripped, no header, no footer, and I think that is correct. You do not want to invite a customer to wander off mid-purchase. So I resisted dropping the full site chrome back in. When a design did call for something, usually payment logos for reassurance, I extended \u003Cstrong>Magento_Checkout\u003C/strong> through a \u003Cstrong>checkout_index_index.xml\u003C/strong> in the theme's layout folder and moved in just the base footer, or brought in the checkout's own header wrapper rather than the site header.\u003C/p>\n\u003Cp>There is a quicker route when you genuinely want more structure back: switch the page layout handle to \u003Cstrong>1column\u003C/strong>, which pulls the standard frame in, then remove the bits you do not want. I found that less of a fight than wrestling the bare checkout template. Either way the styling stays lean, scoped under the \u003Cstrong>checkout-index-index\u003C/strong> body class, and the most common job was just recolouring the progress steps off the default Magento orange, which lives on the before and after pseudo-elements of the step circles.\u003C/p>\n\u003Ch2>Would I still do it this way?\u003C/h2>\n\u003Cp>On an existing Magento store, yes, almost line for line. Move blocks with layout XML, rebuild the footer with editable static blocks, push the menu and anything stateful into modules, and keep the checkout calm. It is a sane setup that survives upgrades. For a new build I would think hard before starting here at all, because a lot of this is effort spent bending a heavy front end to a design, which is exactly the friction that pushed me toward headless in the first place. I wrote up that decision in \u003Ca href=\"/notes/why-i-moved-from-magento-to-headless\">why I moved from Magento to headless\u003C/a>. If you are on Magento and need the theme done properly, this is the way. If you are choosing a platform from scratch, that is a different conversation, and one I am happy to have.\u003C/p>","lg","wysiwyg","",{"author":28},"Headless Digital",[30,31],"magento","dev-workflow",true,"2026-07-10T08:00:00+00:00","2026-06-17T07:14:00+00:00","2026-07-10T08:00:01.537764+00:00",1783670537238]