THE GRUE Get professional WordPress themes

Responsive Menu Module Joomla

More than half of the visitors on a typical Joomla site arrive on a phone, and the first thing they touch is the menu. If that menu is a row of desktop links squeezed into a 375-pixel screen, they leave. We have audited plenty of Joomla sites over the years, and a broken or clumsy mobile menu is still one of the most common problems we find — usually on sites that look perfectly fine on a laptop, which is exactly why the owner never noticed.

The good news is that Joomla gives you several ways to fix it, and most of them do not require touching template code. The main decision is whether your template's built-in menu is good enough once configured properly, or whether you should install a dedicated responsive menu module and publish it in the right position. This guide walks through both routes, plus the details people trip over: breakpoints, duplicate menus, z-index fights and testing.

Everything below applies to Joomla 3, 4 and 5. The admin labels moved around a little between versions, but the concepts — modules, positions, menu assignment — are identical.

Check what your template already gives you

Before installing anything, look at what you have. Almost every template built in the last decade ships with some form of responsive menu: the desktop menu collapses into a hamburger icon below a certain screen width, and tapping the icon reveals the links. If your template does this, your job may be as simple as assigning your menu module to the correct position and adjusting a template parameter or two.

The catch is that templates only apply their responsive behaviour to menus published in a specific position, usually something called menu, nav, header or position-1. Publish your menu module anywhere else and the template's JavaScript and CSS never touch it, so it renders as a plain list. If you are not sure which positions exist in your template, our guide on how to find template module positions in Joomla shows the quick preview trick using ?tp=1.

The built-in menu is usually enough when:

  • Your menu has one or two levels and fewer than ten top-level items.
  • You are happy with the template's default hamburger styling.
  • You do not need extras like search fields, buttons or icons inside the mobile menu.

Reach for a dedicated module when the template menu fails on deep submenus, when you want an off-canvas panel, or when the template is old enough that its "responsive" menu is really just smaller text.

Common mobile menu patterns and when to use them

Responsive menu extensions generally implement one of a few patterns. Knowing the names helps you evaluate what you are installing.

The collapse (dropdown) menu

The classic Bootstrap approach: the menu collapses into a hamburger button, and tapping it expands a vertical list that pushes the page content down. It is simple, predictable and works well for shallow menus. Its weakness is long menus — a thirty-link list that shoves your content off screen feels clumsy.

The off-canvas menu

The menu lives in a panel hidden off the edge of the viewport and slides in over (or pushes aside) the page when the hamburger is tapped. This is the pattern most modern apps use, and it handles long, nested menus gracefully because the panel scrolls independently. Most dedicated Joomla menu modules offer this mode.

The priority-plus menu

The menu shows as many items as fit, then tucks the rest under a "more" item. Nice in theory, fiddly in practice, and rarer in the Joomla extension world. We only recommend it when a client insists on keeping visible links at every width.

Installing and configuring a responsive menu module

Whichever extension you pick from the Joomla Extensions Directory, the setup routine is the same. Here is the sequence we follow on client sites:

  1. Install the extension. Go to System (or Extensions in Joomla 3), then Install, and upload the zip. The extension appears under Site Modules as a new module type.
  2. Create the module instance. Content, Site Modules, New, then choose the menu module type. Give it an obvious name like "Mobile menu — main".
  3. Point it at a menu. In the module options, select the menu it should render — usually Main Menu. The module reads your existing menu tree; you do not rebuild links inside it.
  4. Assign a position. Choose a position that appears in your header. If your template lacks a sensible spot, you can add a new module position to the template in a few minutes.
  5. Set menu assignment. On the Menu Assignment tab, choose "On all pages" for a site-wide menu. A menu that vanishes on some pages is almost always a menu assignment mistake, not a bug.
  6. Save and test unpublished changes on a phone, not just a narrowed browser window.

Getting breakpoints right

The breakpoint is the screen width where the site switches from the desktop menu to the mobile one. Most modules let you set it in pixels. Two rules of thumb:

First, match the module's breakpoint to your template's breakpoint. If the template hides its desktop menu below 992 pixels but your module only activates below 768 pixels, there is a 224-pixel window where visitors see no menu at all. Tablets in portrait mode live exactly in that window.

Second, set the breakpoint by where your desktop menu actually breaks, not by device categories. Load the site, drag the browser narrower, and note the width where menu items start wrapping onto a second line or overlapping the logo. Your breakpoint should sit comfortably above that width. A menu with many items might need the hamburger to kick in at 1100 pixels; a short menu can hold on until 700.

The duplicate menu trap

This is the mistake we see most often. A site owner installs a responsive menu module, publishes it, and now the page carries two menus: the template's built-in menu and the new module. On desktop everything looks fine because the mobile module is hidden — but on phones both hamburgers render, or the old menu shows as an unstyled link list under the new one. Sometimes both menus are present in the HTML at all widths, which means every page ships two copies of the navigation markup. Screen readers announce both; search engines crawl both.

The fix is to make each menu exist only where it is needed:

  • If the module has "hide above breakpoint" behaviour built in, confirm it uses CSS to hide the whole module, not just the hamburger icon.
  • Unpublish the old mobile menu if your template renders one from the same module. Many templates generate the mobile version automatically from whatever sits in the menu position — in that case you configure the template, not a second module.
  • As a last resort, add a couple of media-query rules to your template's custom CSS to hide one menu below the breakpoint and the other above it.

A CSS-only fallback that works anywhere

If you would rather not install anything, you can build a serviceable mobile menu with a checkbox toggle and a dozen lines of CSS dropped into a Custom HTML module — the same technique we cover in our tutorial on creating a Custom HTML module in Joomla. The pattern looks like this:

<input type="checkbox" id="nav-toggle">
<label for="nav-toggle">Menu</label>
<nav id="site-nav">
  <ul>
    <li><a href="/">Home</a></li>
    <li><a href="/about">About</a></li>
  </ul>
</nav>

/* in your custom CSS file */
#site-nav { display: none; }
#nav-toggle:checked ~ #site-nav { display: block; }
@media (min-width: 992px) {
  #site-nav { display: block; }
  label[for="nav-toggle"], #nav-toggle { display: none; }
}

It has no animations and no fancy accessibility niceties, but it degrades gracefully, adds zero JavaScript, and cannot conflict with anything. For a five-page brochure site it is honestly all you need. The downside is maintenance: the links are hard-coded HTML, so this nav will not update itself when you add a menu item in Joomla.

Built-in menu vs dedicated module at a glance

Aspect Template built-in menu Dedicated responsive module
Setup effort Minimal — assign position, done Install, configure, test for conflicts
Deep submenus Often clumsy beyond two levels Usually handled with accordions or drill-down
Off-canvas support Only in newer templates Standard feature
Extra page weight None — already loaded One more CSS and JS file
Risk of duplicate menus None Real — must hide the old menu
Survives a template switch No — behaviour changes with the template Mostly yes

Z-index clashes and other styling fights

Off-canvas and dropdown menus float above the page, which means they compete with everything else that floats: sticky headers, cookie banners, chat widgets, floating share bars. If your open menu appears behind a cookie banner, you have a z-index clash. The menu module sets a stacking value; some other element sets a higher one.

Diagnose it with your browser's inspector: open the menu, inspect the panel, and check its computed z-index, then check the element covering it. The fix is one line of custom CSS raising the menu's z-index above the offender. Keep values sane — if you find yourself typing 999999, step back and figure out which plugin started the arms race. We ran into the same class of problem with floating share widgets, which we cover in our piece on the floating social bar plugin for Joomla.

Also watch for templates that set overflow: hidden on the page wrapper. It silently clips off-canvas panels so the menu opens but stays invisible. Removing the overflow rule, or moving the menu module to a position outside the clipped wrapper, solves it.

Testing across real devices

Browser dev tools with a device toolbar are a fine first pass, but they simulate viewport sizes, not fingers. Before calling the job done, check the menu on at least one real Android phone and one iPhone, and run through this list:

  • Is the hamburger easy to hit? Touch targets should be at least about 44 pixels square.
  • Do submenus open on the first tap? A common failure is the parent link navigating away instead of expanding its children.
  • Can you close the menu by tapping outside it, not just on the icon?
  • Does the menu scroll when it is taller than the screen?
  • Rotate the phone — does the landscape view still show the correct menu?
  • Does anything overlap the menu: banners, notification bars, the browser's own bottom toolbar?

Five minutes with a real phone catches problems that hours of emulator testing misses, particularly hover-dependent submenus that simply do not exist on touch screens.

FAQ

Do I need a separate menu module for mobile and desktop?

Usually not. Modern templates and dedicated menu modules render one menu that adapts to screen width. Two separate modules is a legitimate approach when the mobile menu needs different items than the desktop one, but then you must hide each module outside its width range with media queries, otherwise you get the duplicate menu problem described above.

Why does my menu disappear on some pages?

Check the module's Menu Assignment tab. If it is set to "Only on the pages selected" and a new page's menu item is not ticked, the module simply does not render there. Setting assignment to "On all pages" fixes it for a site-wide menu. The second most common cause is publishing the module in a position that exists in one page layout but not another.

My submenu items do not work on touch screens. Why?

The menu probably opens submenus on hover, and touch devices have no hover. Tapping a parent item fires its link immediately, so visitors can never see the children. Look for a module or template option like "expand on click" or "split parent links", which adds a separate toggle arrow next to parent items. If no such option exists, that alone is a good reason to switch to a dedicated responsive menu module.

Will a responsive menu module slow my site down?

Slightly — expect one extra CSS file and one JavaScript file, usually a few kilobytes each. That is negligible compared with images or third-party embeds. What actually hurts is loading two menu systems at once because the old one was never unpublished, or a module that pulls in its own copy of jQuery when your template already loads one.

The bottom line

Start with what your template gives you: publish the menu in the right position, set a sensible breakpoint, and test on a real phone. If the built-in menu handles your structure, you are done and your site stays lean. Install a dedicated responsive menu module when you need off-canvas behaviour, deep submenus or touch-friendly toggles the template cannot deliver — and when you do, hide the old menu completely so you are not shipping navigation twice. Whatever route you take, the phone test is the only test that counts. For more Joomla walkthroughs like this one, browse the rest of our Joomla hub.