Avada Mobile Menu Not Working: Breakpoints, Scripts and a Hamburger That Ignores You

Six ways an Avada menu fails on a small screen

Write down exactly what happens before you open a single settings panel. Avada menus fail in recognizable patterns, and each pattern points at a different layer. Test logged out, in a private window, on a real phone as well as a narrowed desktop browser, because a logged-in admin often gets uncached pages that hide the problem. The general mobile menu guide covers the cross-theme picture; this page sticks to Avada's own machinery.

• The hamburger does nothing. The icon shows, the tap registers, no menu opens. Almost always a script problem.
• Tablets get a squashed desktop menu. Items wrap onto two lines or run off the edge at widths between a phone and a laptop.
• Two menus, or none. At certain widths both the desktop and mobile header show, or neither does.
• Top-level items open, children do not. Submenus refuse to expand, or a parent link navigates away before its dropdown appears.
• The menu vanishes once the header turns sticky. Fine at the top of the page, gone after a short scroll.
• A mega menu appears as a plain list or a blank panel. Usually a feature that was switched off to save weight.

How Avada decides a screen is a phone

Most modern Avada sites build the header as a Header Layout Section in Avada Layouts, using containers and a Menu element. Older sites, and many imported prebuilt websites, still use the legacy header configured in Global Options. The two systems read different breakpoints, and a mobile menu breaks most often where those numbers stop agreeing with each other or with the design.

A common build uses one container for the desktop header, hidden on small screens, and another for the mobile header, shown only on small screens. That works until someone changes the Medium Screen value, or sets the desktop Menu element to collapse at a width that no longer matches the container rules. Then a band of screen widths, usually tablets, falls through the gap.

Breakpoint gaps: the cause we check first

How to check: open the site in a desktop browser and drag the window from wide to narrow, slowly. Note the exact width where the menu goes wrong. Then compare it with the Small Screen and Medium Screen values in the Responsive panel and with the Collapse to Mobile Breakpoint on each Menu element in the header section. If the broken band starts or ends at one of those numbers, you have found the cause.

Two related checks belong here. In the Menu element's Mobile tab, Mobile Menu Mode decides whether the mobile menu collapses to a button at all, so a menu set to stay expanded will never show a hamburger. And Element Sticky Visibility can hide a menu once its container becomes sticky, which explains the menu that disappears after the first scroll. If whole sections of the layout misbehave on phones, not just the menu, theme not responsive covers the wider problem.

Script settings, stale files and features switched off to save weight

A hamburger that shows but never opens is a JavaScript failure. Avada's Enable JS Compiler, on by default, combines all of the theme's scripts into one file, and its Load jQuery In Footer option moves jQuery to the bottom of the page. The vendor's documentation warns that turning that option on 'can cause JS scripts to break' and that it only takes effect if no jQuery-dependent script is added to the head. Switch off jQuery Migrate Script and any plugin still using deprecated jQuery code can fail with it.

How to check: open the browser console on the broken page and tap the icon. Errors such as 'jQuery is not defined' or '$ is not a function' point at load order. Then look at your caching plugin. If it also combines, minifies or delays JavaScript, it is rearranging files Avada has already combined, and a delayed script may not wake until after the first tap. The JavaScript errors guide explains how to read the console.

Compiled scripts that predate the update

Avada writes compiled CSS and JavaScript into the uploads/fusion-styles and uploads/fusion-scripts folders. After an update, a page can still be served yesterday's compiled script against today's markup. Reset Avada Caches, under Avada > Options > Performance > Dynamic CSS & JS, deletes both folders and rebuilds them. If the theme, Avada Core and Avada Builder are on mismatched versions, sort that first with Avada update problems.

A trigger aimed at nothing, or a feature turned off

Many Avada headers open an off-canvas panel instead of a dropdown. An off-canvas set to open On Click watches an Element Selector, a class or ID such as .menu-trigger. Rename the button's class, or duplicate the header and forget the selector, and the tap reaches nothing. Likewise, the Menu element's Menu option must point at a WordPress menu that still exists after any demo clean-up. Finally, the Performance Wizard's Features step can switch off Mega Menus in Advanced > Features, and the docs warn plainly that a feature you rely on stays broken until you turn it back on.

Getting the menu back, one variable at a time

Work on a staging copy if you have one, and change one thing per test. Changing five settings at once fixes the menu and teaches you nothing about why it broke.

1. 1

   Reproduce it precisely

   Logged out, private window, real phone. Write down the device, the width and the exact failure from the list above.

2. 2

   Clear every layer of cache

   Press Reset Avada Caches, purge the caching plugin, the server cache and any CDN, then test again before touching anything else. Stale files cause more of these than broken settings do.

3. 3

   Line up the breakpoints

   Note Small Screen and Medium Screen in Avada > Options > Responsive. In the header Layout Section, set each Menu element's Collapse to Mobile Breakpoint so the menu collapses before its items run out of room, and set container Element Visibility so every width shows exactly one menu.

4. 4

   Check how submenus open

   In the Menu element, review the Mobile tab and the Submenu tab's Expand Method. Phones have no hover, so make sure a parent item can be opened with a tap.

5. 5

   Undo script tweaks, one per test

   Turn Load jQuery In Footer off, turn jQuery Migrate Script back on, and stop the caching plugin from combining or delaying Avada's scripts. Retest after each change and keep only the ones the menu survives.

6. 6

   Check triggers and features

   Match each off-canvas Element Selector to the trigger's class or ID, confirm the Menu option still names a real menu, and re-enable Mega Menus in Advanced > Features if the site uses them.

7. 7

   Test the full range of widths

   Phone, small tablet, large tablet, both orientations. If the site uses critical CSS, regenerate it from Avada > Critical CSS once the menu works.

Keeping the hamburger working after the next update

• Write the breakpoint numbers down. Small Screen, Medium Screen and each Collapse to Mobile Breakpoint, in one note the next developer will find.
• Give script handling to one tool. Avada's JS compiler or the caching plugin's combining, not both. Page caching stays with the plugin.
• Treat Load jQuery In Footer as an experiment. Try it on staging, test every form and menu on a phone, and accept that the answer may be no.
• Follow the vendor's update routine. ThemeFusion says to clear Avada, plugin, browser and server caches after updating and to rebuild critical CSS after major ones.
• Re-run the Performance Wizard after design changes. A feature it switched off last year may be one the new header depends on.

That routine is dull, which is why it gets skipped. Our hosting and maintenance plans include tested updates and a phone check afterward, and our Avada developers can rebuild a header that was never designed for phones. If the menu is fine but slow to respond, see the Avada speed guide and mobile theme speed.

When a menu needs four settings panels to behave

Step back and count the parties involved in one tap on one hamburger: a Menu element, two containers with visibility rules, a global breakpoint panel, a JavaScript compiler, a jQuery setting, a caching plugin and possibly an off-canvas panel. Each is reasonable alone. Together they form a chain where any link can break, and an update to any one of them can break it again. The other usual Avada faults sit in the Avada repair hub and the troubleshooting section.

In a Next.js build, the menu is one component in the codebase, with its breakpoints in the same stylesheet and its behavior tested before every deploy. Nothing combines or delays its script after the fact. The trade is honest: a higher up-front cost, and layout changes go through a developer. Our Avada vs Next.js comparison weighs it row by row, and Avada to Next.js explains how a site moves with every URL kept, with your team then editing content in Athena CMS. If you just want this menu fixed, our theme troubleshooting service will do that.