Hestia Mobile Menu Not Working: Bootstrap, jQuery and the Tap in Between

Hestia's hamburger is a Bootstrap collapse with two dependencies

Open your page source and find the navbar. Hestia prints a button with the class navbar-toggle and two data attributes: data-toggle set to collapse and data-target pointing at #main-navigation, the box that holds your Primary Menu. Hestia's own code does not open the menu. Bootstrap's collapse plugin does, from assets/bootstrap/js/bootstrap.min.js, and that file refuses to run without jQuery. Its first line throws the error Bootstrap's JavaScript requires jQuery if jQuery is missing when it loads.

Hestia's theme script, assets/js/script.min.js, adds the rest: caret taps for sub-menus, closing the panel when a same-page link is tapped, and a menu-open class on the body that locks page scrolling while the panel is open. It depends on jQuery and jQuery UI core. WordPress prints jQuery in the head, and Bootstrap and the theme script follow in the footer. Keep that order in mind; most Hestia menu failures are that order broken.

Hestia's Bootstrap build collapses the navbar at 768 pixels and below. From 769 pixels up, the toggle is hidden and the full menu shows, so a large phone held sideways may never show a hamburger at all.

Reading the symptom before touching a setting

Test on a real phone in a private tab. A desktop browser squeezed to phone width usually runs logged in, skips the page cache and skips script delay, so it can pass while every customer fails. The cross-theme version of this triage is in WordPress mobile menu not working.

Likely culprits on a Hestia site, in testing order

Script deferral and delay

This is the cause we test first on Hestia because the dependency chain is long. Delay-until-interaction features hold jQuery, Bootstrap and the theme script back until the first tap, so that tap is spent waking the scripts. Defer settings that move jQuery out of the head can break any inline script that expects it, and the console then reports jQuery is not defined. Combining files can put bootstrap.min.js ahead of jQuery. Turn off delay, defer and combine for JavaScript, purge every cache and test. If the menu returns, exclude jQuery, /themes/hestia/assets/bootstrap/js/bootstrap.min.js and /themes/hestia/assets/js/script.min.js, then switch the rest back on. Reading console errors is covered in theme JavaScript errors.

A second Bootstrap from a plugin

Some sliders, form builders and add-on packs bundle their own copy of Bootstrap's JavaScript. Bootstrap 3 attaches its collapse handler when it loads, so two copies attach two handlers, and one tap opens the panel and closes it again before anyone sees it. View the source and search for bootstrap. Hestia's copy lives under the theme's assets folder; anything else is a guest. Switch that plugin off on staging to confirm, then find a setting in it that stops it loading Bootstrap.

An empty Primary Menu location

In 3.3.7 Hestia prints the hamburger only when a menu is assigned to the Primary Menu location. After a menu rebuild, an import or a theme switch the assignment is often lost, and phones simply get no button. Desktop visitors see no menu either, while logged-in admins see only an Add a menu link, which is why the problem can hide. Reassign it under Appearance, Menus, Manage Locations.

Sticky Navbar off on an older release

A forum owner found the open menu would not scroll, hiding every item below the first screen. Themeisle support explained that the panel only scrolled when the navbar was sticky and suggested ticking Sticky Navbar under Appearance, Customize, Header Options, Website, Header. The 3.3.7 changelog lists a fix for mobile menu scrolling with Sticky Navbar disabled, so update first; tick the box only if you are stuck on an older version.

Another plugin's script error

Another forum thread describes level-two items that opened on a PC and not on a phone. Support suspected a JavaScript conflict with another plugin and suggested disabling plugins one at a time. Hestia also ships a style preset for Max Mega Menu; if that plugin runs the Primary location, two menu scripts share the tap, so test with it off. The method is in theme plugin conflicts.

Sub-menus open from the caret, not the label

Hestia treats a parent menu item as a link. Tap its text and the theme script sends the visitor to that page; if the link is just a hash, nothing happens at all. The sub-menu opens from the small caret beside the label. Many owners report a broken sub-menu that is really a caret nobody noticed. If your parent items are placeholders, give each a real page or make the caret larger in your CSS.

The width rules matter too. Reading the 3.3.7 script, the caret handler for phones is attached only if the screen is 768 pixels or narrower when the page loads. Touchscreens 991 pixels or wider get a separate touch handler. Between 769 and 990 pixels neither runs, and the desktop menu relies on the browser imitating hover. A tablet or a big phone turned sideways after loading can land in that band. Version 3.3.4 also reworked keyboard navigation for sub-menus, another reason to be current before debugging.

Getting the Hestia navbar to open again

1. 1

   Update on staging

   Copy the site, update Hestia to the current release and retest. The 3.3.7 menu scrolling fix may be the whole repair.

2. 2

   Check the menu location

   Confirm a menu is assigned to Primary Menu. No assignment means no hamburger.

3. 3

   Strip the optimization

   Disable JavaScript delay, defer and combine, purge page, host and CDN caches, and test logged out on a phone.

4. 4

   Read the console

   Use remote debugging. An error naming jQuery points at load order; an error in another plugin's file points at that plugin.

5. 5

   Look for a second Bootstrap

   Search the page source for bootstrap scripts outside the Hestia folder and disable their plugin to confirm.

6. 6

   Add exclusions and restore

   Exclude jQuery, Bootstrap's script and script.min.js from delay and combine, then switch the other optimizations back on one by one.

7. 7

   Test sub-menus properly

   Tap the caret on each parent item, at portrait and sideways widths, on two different phones.

Guarding the navbar against the next optimizer setting

• Write down every script excluded from delay and combine, and recheck the list after each optimizer update.
• Keep one optimization plugin. Two plugins rewriting the same jQuery chain is how the menu breaks again.
• Before adding a plugin, check whether it bundles Bootstrap's JavaScript, and test the hamburger the same day.
• Update Hestia on staging. Releases arrive every few weeks, and three of the last four touched navigation or the navbar.
• Tap through the menu on a real phone after every theme, plugin or cache change, logged out.

Our hosting and maintenance plans include tested updates on a copy, which is exactly where a broken hamburger should be discovered. If the header itself is missing rather than misbehaving, read Hestia header not showing. If a style change will not appear on the navbar, Hestia CSS not updating covers the caches involved.

When jQuery stands between visitors and your services

Hestia's menu works the way most of the web worked a decade ago: jQuery first, Bootstrap second, the theme third, each waiting for the last. Optimizers exist to break that chain up for speed, and every time they do the menu is the first casualty. The Hestia speed guide explains what that chain costs on a phone, and INP on WordPress and Next.js shows how a slow tap counts against you. Our Hestia review covers who the theme still suits.

A Next.js build ships a menu written as one component, with no jQuery or Bootstrap unless a page needs them, tested before every deploy. It costs more up front and needs a developer for layout changes. Hestia vs Next.js weighs the trade, and Hestia to Next.js explains the move. To keep Hestia and have the menu fixed instead, our theme troubleshooting team works on staging. More guides are in the troubleshooting section.