help1
horizon mega menushopify horizon themeshopify themestheme customization

Postmortem: My Horizon Mega Menu Fix Survived Six Weeks

A postmortem on my Horizon mega menu fix - what broke after a theme update, and the four checks I'd put in the next pass.

help1 Team
Postmortem: My Horizon Mega Menu Fix Survived Six Weeks

You have already tried the obvious things. You opened Online Store > Themes > Customize and pasted a CSS fix into the Custom CSS field; you discovered it has a 500-character cap and your fix is longer than that. You edited _header-menu.liquid directly; the next Horizon update wiped the edit. You found the January 2026 forum thread where tim_tairli posted a clean width: max-content rule, copied it across, and watched it stop matching anything after 3.3.0 shipped. This post is the postmortem of my own version of that loop, and the four checks I am now putting in front of the next pass.

What broke

A merchant pinged me on a Wednesday afternoon. Her Horizon mega menu was back to spanning the full browser width. The submenu items had drifted left of the parent links again. The small CSS fix I shipped six weeks earlier was, as far as either of us could tell, doing nothing.

I opened theme editor and went hunting. The CSS was still sitting in the custom Liquid section in her Footer Group, exactly where I parked it. The selectors were still in the file. They were just no longer matching anything on the rendered page. No console error. No theme-editor warning. The fix had failed silently.

Horizon 3.5.0 had shipped over the weekend. The merchant had accepted the update from her admin without thinking about it, because she had no reason to think about it. Shopify does not flag navigation-affecting changes when you accept a theme update. A flag would have helped. It is not there.

Why the fix was always going to break

My fix leaned on three Horizon-specific things, and every one of them was liable to change between minor versions:

  1. The selector .header-flyout__submenu-inner. Horizon has renamed or restructured submenu inner elements at least once before, between 3.2.x and 3.3.0. When _header-menu.liquid changes, derived class names move with it.
  2. The role of .header__underlay. I had display: none on it to kill the full-width background bleed. After 3.3.0 the underlay started driving the scroll-state transparency on a sticky header as well, and around 3.5.0 the markup that uses it shifted again.
  3. The absence of a public diff. The Shopify/horizon GitHub repository was accidentally archived in May 2026, frozen at 3.4.0, while the Theme Store advanced to 3.5.0 and then 3.5.1. Shopify staff acknowledged the archive was a mistake, but as I write this, 3.5.0 and 3.5.1 are still not in the public repo. There was no public way to see what changed without diffing the new theme files against my backup by hand.

This is the part I want to be honest about. I knew the CSS had a half-life. That is why I had put it in a Footer Group custom Liquid section in the first place rather than directly inside _header-menu.liquid. What I did not do was assume the next minor release would also move the selector. I assumed "survives updates" was a property of the file I parked the CSS in. It is a property of the file plus the class names it depends on, and only the first half is mine to control.

What I'd catch earlier next time

Four things go into the playbook before any horizon mega menu fix ships now:

  1. Pin the Horizon version in the section comment. Every custom CSS block aimed at navigation now starts with a comment like /* Tested on Horizon 3.5.1 - re-verify after each minor */. Small thing. The point is that future-me, looking at the file in five months, can tell at a glance whether the rule has been checked against the current theme version.
  2. Ship a "fix sentinel" that proves the selector still matches. Add a tiny element styled by the same class chain whose appearance is invisible under success and obvious under failure. If your CSS rule's only effect is on layout, you cannot tell from a screenshot whether the rule stopped matching or whether the layout happens to look the same. A sentinel would have caught this in the merchant's first preview after the update, not six weeks later.
  3. Duplicate the theme before accepting any Horizon update, and walk every navigation path on real devices. The theme editor preview hides at least one class of mobile-only menu bug, and community threads have been flagging that for months. I keep forgetting and I keep paying for it.
  4. Decide up front whether the merchant wants a code maintenance contract or a navigation app. A working CSS fix is cheap to write once and expensive to re-apply forever. For merchants who do not want to think about Horizon's update cadence, a navigation app like Globo Mega Menu trades a small monthly subscription for surviving theme updates. I used to think the code path was always the right one. I was wrong about that for most of last year, and I have been recommending the app more often since.

If you are reading this from inside the loop, your horizon mega menu fix worked, then stopped, and you are not sure which CSS selector to chase this time without burning another evening on it, the first 15 minutes with a help1 expert is free and that is usually enough to figure out which path is right for your store. For the wider view of what else tends to break on Horizon between minor releases, my earlier roundup of Horizon bugs we see in audits is the companion piece to this one.

The unsolved cases

A few open questions I have not solved, and want to be honest about:

  • The conditional-Liquid approach (a menu_style select added to the Menu block schema in _header-menu.liquid) does not reliably render three-level submenus. Two-level works fine. If you have a horizon mega menu with deeply nested categories, the snippet path is not stable today.
  • Dwell, the Horizon variant, has subtly different selectors. The community CSS fix above has been reported to silently fail on Dwell. I have not done a full selector audit across the two themes. If your store is on Dwell rather than vanilla Horizon, expect to do the inspector dance yourself.
  • The mega menu still has no native way to attach images to page-type menu links. Only collection-type and product-type. Merchants who want editorial navigation are still doing Liquid edits, and those Liquid edits are the exact thing that gets clobbered on update.

One last thing

What I keep coming back to, after enough of these audits, is that a horizon mega menu fix is not so much a CSS rule as a small ongoing maintenance commitment, and merchants who burn out on Shopify tend to be the ones who keep mistaking one for the other.

Still stuck? Talk to an expert.

Our vetted Shopify experts can fix this issue for you in a live session. $39 per session. Your first 15 minutes are free.