Shiftnav Pro - WordPress Plugin

A Practical Guide to Setting Up ShiftNav Pro for a WordPress Mobile Menu

ShiftNav Pro is best viewed not as "just another hamburger button," but as a dedicated mobile navigation layer for WordPress. In this guide, we will walk through how to prepare your site, assign the right menu, configure the panel, choose submenu behavior, add useful content inside the slide-out area, and test the setup in real mobile use cases.

This guide is written for a site owner, editor, webmaster, or developer who already understands how WordPress menus are structured but wants to make mobile navigation clearer without rewriting the theme. We will not cover purchasing, license keys, or activation workarounds. The focus here is on practical configuration of an existing plugin, theme compatibility, troubleshooting, and safe post-launch validation.

The core idea is simple: ShiftNav Pro creates an off-canvas panel that opens from the edge of the screen, pulls items from a WordPress menu or selected menu location, and can run independently from the theme's desktop navigation. Problems usually come not from the concept itself, but from the wrong breakpoint, a poor toggle bar insertion point, a conflicting theme menu, CDN-served fonts, a fixed header, or an overly complex menu structure.

What Problem the Mobile Panel Solves and When You Actually Need It

A typical WordPress mobile navigation problem looks like this: the theme shows a horizontal menu on desktop, but on a phone it turns into a long dropdown list, clashes with a fixed header, covers the hero area, or forces the user to scroll through multiple levels with no clear structure. ShiftNav Pro solves that specific problem by separating mobile navigation from the theme's visual implementation and displaying it as a slide-out panel in an app-style format.

The plugin is especially useful on sites where the menu does not fit on one line, includes 2-3 levels of nesting, relies on quick access to key sections, and uses a theme that offers limited control over mobile behavior. On a service catalog, you can keep the theme's desktop menu for large screens while showing a ShiftNav panel on phones with shorter items, icons, and search. On a content site, you can move categories and popular pages into a mobile-friendly structure without crowding the top of the page.

That said, ShiftNav Pro does not have to replace your entire site navigation system. It can work as a mobile layer on top of your existing structure. That matters for older classic themes, sites with custom headers, Genesis-based projects, sites using UberMenu, and cases where the theme has a strong desktop menu but a weak mobile version.

Who This Approach Works Well For

The plugin works well for sites where a mobile visitor needs to open the main menu quickly, move into a section, go back, and avoid getting lost in a long hierarchy. Strong use cases include:

• A service website with multiple categories where submenus should open cleanly instead of stretching across the whole screen.
• A store or catalog where the mobile header is crowded with a logo, search, account buttons, and a cart.
• A blog or media project with many categories, where fast access to site structure matters more than decorative animation.
• A site using a classic theme whose mobile menu feels outdated or does not work well with a fixed header.
• A project that needs separate mobile navigation without breaking the desktop header or editing theme files.

When ShiftNav Pro Should Not Be Your First Move

In some cases, it makes more sense to check the built-in theme or WordPress options first. If the site uses a block theme and the native Navigation block already behaves well on mobile, a separate off-canvas plugin may be unnecessary. If the menu contains only three links and the header already adapts properly, adding another layer will just make maintenance harder. If the project needs a large desktop mega menu with columns, widgets, and a complex layout, ShiftNav Pro can work as a mobile add-on, but not as a replacement for a full mega menu.

Practical rule of thumb: install ShiftNav Pro when mobile navigation is a distinct problem on the site. If users can already find what they need easily on a phone, measure the actual pain point first instead of adding another plugin for a nice effect.

What to Check Before Installing It on a Live Site

Before installation, it is important to understand not only whether the plugin fits your site, but also how it will integrate with the current theme. ShiftNav adds its own toggle bar, creates or uses a WordPress menu, and can hide the theme menu by CSS selector. A quick pre-check will save more time than debugging a missing button or duplicate navigation later.

WordPress Menu Structure

Open Appearance > Menus and see whether you already have a separate menu for mobile. If the desktop menu is too long, do not copy it blindly. Mobile users usually do not need every utility item that makes sense on a wide screen. Build a compact menu instead: main sections, categories, contact info, account access, search, or a quick jump to a form. Then assign it to the ShiftNav [Main] location or select it inside the appropriate Pro instance.

Pay close attention to nesting. A deeply nested structure hurts navigation even inside a well-designed slide-out panel. For most sites, two levels are enough: a parent section and one set of child items. Keep a third level only where it clearly helps, such as in a service catalog or documentation hub.

Theme Header, Fixed Elements, and Extra Toggle Buttons

If the theme already outputs its own mobile hamburger button, enabling ShiftNav Pro may leave you with two buttons on a phone. That is not always a plugin error. In most cases, one button belongs to the theme and the other belongs to ShiftNav. In that situation, you need to decide which navigation stays primary. If you keep ShiftNav, hide the theme menu using a selector in the plugin settings or with targeted CSS in the theme settings.

A fixed header needs a separate review. The slide-out panel should sit above the theme's visual layer and should not end up underneath a sticky header. If the theme uses aggressive z-index values or ships its own mobile menu scripts, test on a site copy or staging environment first. Do not disable all theme scripts blindly: identify the specific element causing the conflict.

Viewport and Small-Screen Behavior

The official ShiftNav documentation specifically calls out the viewport meta tag. Nearly all modern themes already include it, but older or heavily customized themes can still get it wrong. If the mobile panel looks too wide, the page scales strangely, or the breakpoint triggers in the wrong place, verify that the theme has a proper viewport setting. This guide does not treat theme file edits as a required step because the exact path depends on the theme, but the symptom is worth recognizing in advance.

Cache, Optimization, and CDN

Optimization plugins may combine or defer CSS and JS, and a CDN may serve Font Awesome from another domain. On a regular menu, that may go unnoticed, but in ShiftNav, icons, submenu arrows, and smooth transitions depend on frontend assets. After installation, clear cache, test the menu without minification, and then re-enable optimizations one by one. If icons disappear, check not only CSS but also CORS headers for fonts.

Installation and Initial Validation Without Unnecessary Risk

Installing ShiftNav Pro is similar to a standard WordPress ZIP plugin install: upload the archive through Plugins > Add New > Upload Plugin, activate it, and go to the settings. If the free ShiftNav version was previously installed, the official documentation notes that Lite and Pro are separate plugins with a shared codebase, and only one should be active at a time. Pro attempts to deactivate Lite automatically, but it is still worth checking manually.

After activation, do not start with colors and icons. First, get three basic states working: the plugin is active, the menu is assigned, and the toggle bar appears at the correct screen width. Only then does it make sense to work on styling and advanced content.

Basic Launch Sequence

1. Upload and activate the ZIP plugin using the standard WordPress screen.
2. Check the list of active plugins: if ShiftNav Lite is installed, leave only ShiftNav Pro active.
3. Create or select a menu in Appearance > Menus.
4. Assign that menu to the ShiftNav [Main] location through Manage Locations.
5. Open Appearance > ShiftNav and go to the toggle bar settings.
6. Set the breakpoint where the mobile panel should appear instead of the theme menu.
7. Save changes and test the site in responsive browser mode and on a real phone.

At this stage, the design does not need to be perfect. The goal is to confirm that the button opens the correct panel and that the panel shows the right WordPress menu items. If the menu is empty, the cause is almost always the assigned location or the selected menu inside the instance, not colors, fonts, or cache.

How to Confirm the Correct Menu Layer Is Active

Reduce the browser width below the selected breakpoint. A ShiftNav toggle bar or other chosen trigger should appear at the top of the site. Open the panel and verify that the items match your mobile menu, not some random utility menu from the theme. Then increase the width above the breakpoint: if the setup is truly mobile-only, the toggle bar should disappear and the theme's desktop navigation should return to its normal appearance.

Critical expected state: below the breakpoint, the user sees one clear mobile menu trigger, and above the breakpoint, they do not get an extra ShiftNav button next to the desktop navigation.

Why You Should Not Hide the Old Theme Menu Too Early

Hiding the theme menu too quickly often leads to missing navigation on tablets or empty space on desktop. First, identify the actual theme menu selector using developer tools. Then use ShiftNav's hide setting or CSS only for the required width range. If the entire header disappears, the selector is too broad. In most cases, you want the menu container itself: something like .primary-nav, #primary-menu, or a specific class wrapping the top link list.

Toggle Bar, Breakpoint, and Theme Injection Point

The toggle bar is the top strip or button that opens the slide-out panel. In ShiftNav, this is the element that most often needs deliberate configuration. It should appear at the right moment, occupy the expected place in the header, remain accessible to keyboard users and screen readers, avoid conflicts with the WordPress admin bar, and not vanish because the theme is missing the required hook.

Breakpoint: Where the Desktop Menu Stops Working

The official documentation suggests 960 or 767 pixels as practical starting points. Those are not magic numbers. 960 often works well on sites where the desktop menu already feels cramped on tablets. 767 is closer to the classic phone breakpoint. The right choice depends on your actual header layout: if menu items start wrapping or colliding with the logo around 900 pixels, set the breakpoint higher. If the desktop menu still works well on tablets, keep ShiftNav for phones only.

The test is simple: open the homepage, a page with a long title, a catalog page, and a page with a form. On each one, reduce the browser width and watch for the point where the standard menu stops being comfortable to use. That width should drive the setting, not an abstract value copied from someone else's example.

What to Choose for a Typical Site

• For a service site with 5-7 menu items, you can start with 767 if the header does not break on tablets.
• For an online store, catalog, or site with long section names, 960 is often the better starting point.
• For a theme with a wide header, large logo, and extra buttons, test an in-between value based on the actual point where elements begin to interfere with each other.

Toggle Bar Injection: Header or Footer

In the ShiftNav documentation, the primary option in newer settings is injection through wp_body_open, which places the toggle near the start of the page content. That is better for accessibility because the toggle appears earlier in the keyboard and screen-reader reading order. If the theme does not support that standard hook, the toggle bar may not appear. In that case, the practical workaround is to switch Toggle Bar Injection to Footer, which uses wp_footer.

An important point: if Footer brings the button back, that does not mean the problem is fully solved. It is a sign that the theme may be outdated or incomplete in its support for standard WordPress hooks. For a quick launch, switching the setting is enough. For long-term maintainability, it is better to update the theme or ask the developer to add proper wp_body_open support.

Hiding the Theme Menu Without Breaking the Header

ShiftNav Pro can hide the theme menu by CSS selector. That is more convenient than editing templates, but it requires precision. Do not target the entire header if it also contains the logo, search, cart, or account button. You want only the menu that truly duplicates ShiftNav. In Chrome DevTools, find the top-level nav or div wrapping the ul list and verify the selector across multiple pages.

If the site uses UberMenu, the ShiftNav documentation describes a separate hiding workflow for it. For UberMenu 3, you can use the dedicated Hide UberMenu option; in older cases, use UberMenu selectors. The goal is not to make two plugins compete for the same mobile view, but to keep the desktop tool on large screens while letting ShiftNav take over confidently on mobile widths.

The Menu Panel: Side, Width, Skin, and Readability

Once the basic setup works, configure the slide-out panel itself. This is where ShiftNav Pro differs from simple mobile menus: the panel acts like a separate interface container with its own opening side, width, skin, color scheme, top image or logo, submenu behavior, and advanced content. A strong panel is not just "good-looking" but predictable: the user understands where they are, how to go back, and which item to tap next.

Left or Right Side

For most left-to-right sites with a standard logo and menu flow, opening from the left usually feels more natural: the user taps the hamburger button and sees the menu slide in from the start of the reading direction. Opening from the right can make sense if the key header actions live on the right, the site emphasizes account actions, or the cart and profile controls are placed there. Choose the side based on user expectation, not personal preference.

Test the chosen side on a real phone. On small screens, a user's thumb often sits lower on the device, while a top toggle may be harder to reach one-handed. If the theme already includes a bottom mobile bar or sticky buttons, make sure ShiftNav does not open over critical elements like a checkout button or floating chat.

Panel Width and the Sense of Space

The Pro changelog notes support for configurable panel width and more modern CSS handling for width and height. In practical terms, the panel should not cover so much of the screen that users lose all context, but it also should not be too narrow for long menu labels. On phones, a width that takes up most of the screen is usually comfortable because it still feels like a panel sliding in from the side while leaving enough room for text.

If your menu contains many long labels, shorten the labels first. Panel width should not be used to compensate for poor information architecture. For example, instead of "Comprehensive WordPress Website Support and Growth," a mobile menu label could simply be "WordPress Support," with the fuller explanation left on the destination page.

Skin and Color Strategy

ShiftNav offers built-in skin options and color settings through the Customizer. On a site with a dark header, a dark panel can feel cohesive, but check text contrast and the appearance of active items. On content-heavy or educational sites, a light panel often reads better. The main rule is simple: the menu should feel calmer than the content. If every item looks like a bright button, users stop seeing the hierarchy.

The active item and expanded submenus should stand out, but not shout. Use one accent color for the current section, one neutral color for regular items, and a clear state for arrows. If icons are enabled, they should support scanning, not turn the list into a wall of unrelated symbols.

Readability Check

Do not test the panel only on the homepage. Open a long post, a page with a form, a product page, a page with a sticky header, and a page with the admin bar for a logged-in user. The menu should open, close, scroll internally, and avoid blocking important actions. If the page background moves with the panel or content disappears, go back and review wrapper settings, body shift behavior, and conflicts with fixed elements.

Pro Submenus: Accordion, Shift Panels, and Multi-Level Navigation Behavior

One of the main reasons to use the Pro version is control over submenu type. In the free version, submenus are always visible, while ShiftNav Pro adds more options, including accordion and shift submenus. These are not just decorative effects. The submenu type directly shapes how users understand the site's hierarchy on a narrow screen.

Always Visible: When Simplicity Beats Interaction

The always-visible submenu mode works best for short structures, such as one parent item called "Services" with 3-4 child categories. Users can see the section content immediately, do not need an extra tap, and do not have to guess what the parent link does. The downside is obvious: if you have many such sections, the panel becomes long and heavy to browse.

Use this option when the menu is small and the nested layout helps users read the site structure like a table of contents. If people need fast access to a subcategory and the total number of items is still low, an expanded layout may be more useful than any effect.

Accordion: Compact Without Losing Context

An accordion submenu expands beneath the parent item and pushes lower items down. This mode works well for service catalogs, knowledge bases, category-heavy blogs, or stores where users want to keep the parent section and neighboring groups in view. In the ShiftNav documentation, this type is represented by a downward arrow, making it clear that the item can be expanded or collapsed.

An important setting here is deciding whether clicking the item text should open the page while clicking the arrow expands the list, or whether the whole item should act as a toggle. If the parent page contains a useful overview, do not make it inaccessible. If the parent item serves only as a group label, you can disable the link or configure the behavior so users do not land on an empty intermediate page.

Shift Submenus: Focus on the Current Branch

Shift submenus open a new layer on top of the current panel: the selected branch stays in focus and a back button appears. This is a strong option for large catalogs, documentation, and sites with deep section trees. It reduces noise because the user sees one context at a time instead of the entire list at once. The tradeoff is that if the structure is confusing, it becomes harder for users to tell where they are.

Use shift submenus where a parent item has many child pages and the user benefits from an immersive drill-down mode. On short menus, this can be excessive. The deeper the structure, the more important it is to have a clear Back button label and obvious parent item names. If a user taps back and does not understand which section they returned to, the issue is in the menu architecture, not the animation.

Global Setting and Individual Exceptions

The documentation notes that submenu type can be set globally in the control panel or individually for a specific menu item. In practice, it is best to choose one global mode for most items and configure exceptions only where they are justified. For example, you might use accordion by default for a service catalog, but assign a shift submenu to a "Documentation" section with many articles. That gives users a consistent rhythm instead of random behavior from one section to the next.

Icons, Top Content, Search, and Useful Elements Inside the Panel

ShiftNav Pro makes it possible to turn the mobile panel into more than just a list of links. It can become a compact navigation block with a logo, search, phone number, map, user mini profile, and HTML or shortcode content before or after the menu. This helps when mobile users need more than section links, such as quick contact access, account entry, or on-site search.

Icons for Menu Items

The Pro documentation describes choosing Font Awesome icons for individual menu items through the item settings panel. Icons can help users quickly distinguish items like "Catalog," "Contacts," "Account," "Cart," or "Support," but they should feel predictable. Do not add icons just for decoration. If two items mean roughly the same thing, icons can easily create more confusion instead of less.

A practical minimum is to add icons only to the most important actions. For example, a house for the homepage, a magnifying glass for search, a phone for contact, and a user silhouette for account. If the site uses its own icon set, the Pro version supports a custom icon class, but that option requires careful verification of CSS and font loading.

Logo and the Top Area of the Panel

The documentation shows that you can insert text, HTML, or a shortcode into Toggle Content, and for a logo, use a regular img tag with the image URL from the media library. In practice, this is useful when the top strip of ShiftNav should preserve the site's brand identity. But the image should stay small: a tall logo will enlarge the header and take space away from the actual content.

You can also add content before or after the menu item list. For example, before the menu, you might place a compact logo or short trust line; after the menu, a phone number, business hours, or a support link. Do not turn the panel into a second homepage. On mobile, every extra block pushes the main menu items lower.

Search, Login/Logout, and a User Mini Profile

The Pro documentation includes shortcodes for search, toggle bar search, login/logout, and a user mini profile. Use them only when they solve a specific problem. On a content site, search inside the mobile panel may matter more than a long category list. On a membership site or store, login and logout links can help users reach their account faster. On a simple brochure-style site, those elements may add unnecessary noise.

Treat these elements as working interface components, not decorative inserts. Search should open correctly, accept a query, send the user to the right results page, and stay open reliably. Login/logout should reflect the user's actual authentication state. If the site uses page caching for both guests and logged-in users, verify that personal elements do not end up in a cached page shown to everyone.

Safe CSS for Logo Alignment

The official documentation includes an example for aligning toggle bar content with CSS. Below is a cautious adaptation for a case where the toggle bar includes a small logo and some text. It is best added in the theme's Additional CSS field or a safe CSS module, not in plugin files.

.shiftnav-main-toggle-content,
.shiftnav-main-toggle-content img {
  vertical-align: bottom;
}

.shiftnav-main-toggle-content img {
  max-height: 25px;
  width: auto;
}

.shiftnav-main-toggle-content a {
  padding-left: 5px;
}

After adding it, open the site on a phone and check two things: the logo does not stretch the toggle bar vertically, and the text next to it does not stick to the image. Rolling it back is simple: remove this CSS from Additional CSS and clear cache. If the theme already defines its own ShiftNav styles, do not add stronger selectors unless you truly need them.

Secondary Instances: Separate Panels for Different Jobs

Secondary instances are another Pro feature that goes beyond color customization. They let you create an additional ShiftNav panel with its own menu and settings. This is useful when one mobile navigation panel is not enough. For example, the main menu may open from the left, while an account menu, store section menu, or support menu opens from the right.

When an Additional Instance Makes Sense

An additional instance makes sense only when it supports a separate use case. A poor use case would be duplicating the same menu in a different color. A good one would be a dedicated "My Account" menu for logged-in users, a separate documentation menu, a section menu for the catalog, or a support panel with search, a phone number, and links to common questions.

The documentation explains that the main panel uses the ShiftNav [Main] location, while a secondary instance gets its menu assigned in that instance's dedicated tab. You can choose a specific menu through Display Menu or use a Theme Location. If both values are set, Display Menu takes priority. This matters when troubleshooting: sometimes an editor assigns a menu to a location, but the instance still shows a different menu because a specific list has been selected in the instance settings.

How Not to Confuse Users with Two Panels

If the site uses two panels, each one needs a clear trigger and a clear role. For example, the left toggle opens "Menu," while the right toggle opens "Account" or "Catalog." Do not use identical icons and identical labels. Users should understand in a second what will happen when they tap each one.

Also verify how the panels behave together. The changelog mentions an improvement where the main toggle closes an open secondary menu. That is the logical behavior: two competing panels should not remain open on screen at the same time. After setup, open the secondary panel, then tap the main toggle and make sure the interface does not freeze, leave an overlay behind, or lock page scrolling.

Precise Integration Through the PHP API

For developers, ShiftNav documents the shiftnav() and shiftnav_toggle() functions. These allow you to output a panel or toggle for a specific instance. Not every site needs this, but it is useful for precise integration when a secondary instance should appear only on certain pages. The official example shows adding a panel through wp_footer and explains that automatic generation of additional instances can be disabled if needed.

Add this kind of code only through a child theme or a safe snippets plugin, and only after testing it on a site copy. Do not edit ShiftNav Pro files or drop PHP into a random template. If the goal is just a normal mobile menu, use the settings panel. The PHP API is for conditions: a specific page, a separate section, a user role, or a manually controlled toggle location.

add_action( 'wp_footer', 'my_mobile_shop_shiftnav' );

function my_mobile_shop_shiftnav() {
  if ( is_page( 'shop-help' ) && function_exists( 'shiftnav' ) ) {
    shiftnav( 'shop' );
  }
}

This example shows the principle, not a universal recipe. The shop identifier must match your instance ID, and the is_page() condition must match a real page on your site. To validate it, open the target page and a neighboring page, and confirm that the extra panel appears only where intended. To roll it back, remove the snippet and clear cache.

Practical Example: A Mobile Menu for a Service Website

Let us look at a specific example. Imagine a WordPress service site where the desktop header contains a logo, menu items for "Services," "Pricing," "Case Studies," "Blog," and "Contact," plus a request button. On a phone, the theme menu expands into a long list and covers the hero area. The goal is to keep the desktop header as is, while enabling ShiftNav Pro for mobile users with a short off-canvas panel where services expand as an accordion, contact and the request action are easy to reach, and the old theme mobile toggle is hidden.

Goal and Preparation

The goal is to get one clear menu button at mobile widths, a left-side slide-out panel, compact service sections, quick access to the request form, and no duplicate theme menu. Preparation:

• Create a backup or use a staging site.
• Verify that ShiftNav Pro is active and the free ShiftNav Lite plugin is not active at the same time.
• Create a menu called "Mobile Main" in Appearance > Menus.
• Add only the mobile-relevant items: "Home," "Services," child service pages, "Pricing," "Case Studies," "Blog," "Contact," and "Request a Quote."
• Find the CSS selector for the theme's old mobile menu using the browser inspector.

Step-by-Step Setup

1. Assign the "Mobile Main" menu to the ShiftNav [Main] location.
2. Open Appearance > ShiftNav and confirm that the main instance is using that location.
3. In Toggle Bar, set the breakpoint based on the actual width where the theme menu starts to break. For this example, start with 960.
4. Leave Toggle Bar Injection set to Header if the button appears. If the theme prevents it from appearing, switch to Footer and record that as theme technical debt.
5. In the menu hiding settings, enter the selector for the old mobile toggle or theme menu container, but not the entire header.
6. In the panel settings, choose the left side, an appropriate width, and a calm skin that contrasts with the site's background.
7. Set the parent "Services" item to accordion so child items expand underneath it.
8. For the "Request a Quote" item, configure Scroll To with a form selector such as #contact if that form exists on the current or destination page.
9. Add icons only to the most important items: search, contact, request, or account.
10. Save the settings, clear cache, and test the site in a private browser window.

Validating the Outcome

Your check should mimic real user behavior. Open the site on a phone, tap the toggle, expand "Services," go to a child page, go back, open the menu again, and tap "Request a Quote." If Scroll To is configured for that item, the page should scroll to the form and the menu should close after the scroll completes. If the selector is not found on the current page, ShiftNav should follow the menu link and then try to locate the target element there.

Then test widths above and below the breakpoint. On desktop, the mobile bar should not remain visible. On tablets, there should not be two toggles. In admin mode with the WordPress top bar visible, the menu should not hide beneath the admin bar.

A Common Pitfall

If the parent "Services" item is also an important landing page, do not turn the entire item into a plain toggle with no navigation. Split the behavior: the text opens the overview page, and the arrow expands the child services. If the parent page is not needed, then you can disable the link or use the item only as a group label. This small decision has a major impact on mobile conversions: either the user reaches the service overview or gets stuck repeatedly expanding a list.

Scroll To, Action Items, and Connecting the Menu to Page Content

A mobile menu can contain two very different types of navigation. The first is a standard link to a page or category. The second is an action within the current page: scroll to a form, pricing block, map, service description, or FAQ section. ShiftNav Pro supports this through the Scroll To setting on a menu item. It is easy to underestimate because it looks like a minor item-level setting, but on mobile it can turn the menu into a fast path to action.

Scroll To works by selector. In the field, you enter an element ID or class such as #contact or .pricing. When the user taps the item, the plugin looks for a matching element on the page. If the element exists, the page scrolls to it and the menu closes after the scroll finishes. If the element is not on the current page, the user follows the regular item link, and ShiftNav then tries to find the target element on the newly loaded page. For service sites, landing pages, and long-form pages, this is more convenient than forcing people to hunt for the form manually.

How to Choose a Stable Selector

The most common mistake is using a random class generated by a page builder. Many page builders and themes generate technical classes that can change after a block update, section duplication, or template edit. For Scroll To, it is better to use a clear manually assigned ID. If the request form sits inside a "Contact" block, give the container the ID contact and use #contact. If pricing sits in a "Pricing" section, use #pricing or another stable identifier.

Do not use the same ID on multiple blocks. In HTML, an ID must be unique. If a page contains two elements with id="contact", the browser may scroll to the first one and send the user to the wrong place. If you need to target multiple similar blocks, use different IDs such as #contact-form, #office-map, and #callback. This is especially important on pages where the form appears both mid-page and near the bottom.

Scroll Offset with a Fixed Header

If the site has a fixed header, sticky bar, or top admin bar for logged-in users, scrolling may technically stop in the right place while the target section heading ends up hidden behind the header. ShiftNav includes Scroll Offset in the general settings for exactly this reason. Offset adds spacing so the target element does not stick to the top edge of the viewport.

Test the offset across different pages. Some themes change header height after scrolling: it starts tall and then becomes compact. In that case, do not chase mathematical perfection. Choose a value that lets the user see the heading and the start of the block in most real situations. If the form or button lands too low, reduce the offset. If the heading hides under the sticky bar, increase it.

Action Items vs. Regular Pages

Not every mobile menu item should use Scroll To. For sections like "Blog," "Case Studies," "Catalog," or "About," regular links are usually better. Scroll To works best for actions that live inside the current or destination page: request forms, maps, pricing, testimonials, FAQs, or a "how to get started" section. If every item becomes an anchor jump, users lose the sense of site structure and start landing in the middle of pages with no context.

On a service website, a strong mobile structure might look like this: "Services" expands as an accordion, child services open separate pages, "Pricing" links to the pricing page, "Request a Quote" scrolls to the form, and "Contact" links either to the contact page or a map block. In this setup, the menu blends navigation with action. That works better than a long panel full of generic links.

Working Alongside UberMenu and Desktop Navigation

If the site uses UberMenu on desktop, ShiftNav Pro is best treated as a mobile companion rather than a competitor. Official SevenSpark materials specifically mention setups where ShiftNav complements UberMenu on mobile screens. In practical terms, the desktop mega menu stays where it is useful, while mobile users get a simpler off-canvas layer.

In that kind of setup, do not move every complex mega menu element into the mobile panel. Widgets, columns, promo blocks, and large images often work well on wide screens but get in the way on a phone. It is usually better to create a dedicated mobile menu with the same key paths but without the heavy visual layout. If you need to expose catalog categories, use accordion or a shift submenu. If you need to feature a promo link, add one neat item or a short HTML block after the menu.

Integration check: above the breakpoint, the desktop navigation tool should work; below the breakpoint, ShiftNav Pro should take over. Users should never see two navigation systems at the same time, and they should not lose access to key sections.

Mini Checklist for Action Items

• The item has a standard page link, and the target block actually exists on that page.
• The Scroll To field uses a stable selector, ideally a manual ID rather than a random builder class.
• After the tap, the menu closes and the user sees the start of the intended block.
• For a fixed header, Scroll Offset is configured, or the chosen target block does not disappear under the header.
• If the selector is not found, the link still takes the user to a useful page instead of nowhere.

This area deserves especially careful testing if the mobile panel affects lead generation. A broken standard link is annoying but easy to notice. A broken Scroll To action often feels like "nothing happened," and the user simply closes the menu. That is why every time you edit a form, page builder layout, or template, you should re-test your action items.

Checking the Final Setup: UX, Accessibility, Performance, and SEO

A mobile menu affects more than appearance. It changes interaction order, navigation access, the number of visible links, focus behavior, and the way frontend assets load. That is why the setup should end with a short but systematic quality review.

UX Check

Open five pages: the homepage, a long post, a service page, a contact page, and a page with a form. On each one, test the same set of actions:

• The toggle appears where users expect it and is not covered by a cookie banner, sticky button, or admin bar.
• The panel opens from the selected side and closes in a clear, predictable way.
• Submenus expand using the behavior chosen for the site's structure.
• A long panel scrolls internally, and the page behind it does not interfere with browsing the items.
• After following a link, the menu does not leave behind a dim overlay, an empty layer, or locked page scrolling.

Accessibility Check

The ShiftNav Pro changelog mentions accessibility improvements such as keyboard handling, Escape-to-close, a screen-reader close button, an aria label for the toggle, focus behavior, and search updates. That does not remove the site owner's responsibility to test. Tab through the menu, open and close the panel from the keyboard, test Escape, and make sure focus does not slip behind an invisible layer. If you changed the toggle bar HTML or added a custom toggle through PHP or the API, accessibility testing becomes especially important.

Performance and Cache Check

ShiftNav Pro itself should not become the main reason a page feels heavy, but any extra CSS, fonts, icons, search features, and HTML content add to the frontend layer. After configuration, clear cache and inspect the browser console and Network tab. If Font Awesome resources are being blocked, address CORS or create a CDN exclusion. If an optimization plugin defers JavaScript so aggressively that the menu opens only on the second tap, exclude the plugin script from that delay, but do it surgically.

SEO and Crawlability

A mobile menu should not hide important links from users or replace a meaningful site structure with a cluster of context-free buttons. Search engines evaluate the page as a whole, but for UX and internal linking, it matters that mobile visitors can reach key sections. Do not bury important categories in mobile navigation if those categories lead to your most important pages. At the same time, do not overload the panel with utility links that could live in the footer.

A good real-world validation: ask someone who did not configure the site to find a service price, a contact method, a popular section, and the request form on a phone. If they can do it without hints, the navigation is better configured than one that merely slides in nicely.

Common ShiftNav Pro Issues and Straightforward Troubleshooting

Mobile menu problems often look similar on the surface, but with ShiftNav Pro the causes are usually tied to specific settings: toggle injection, breakpoint, theme hiding, Font Awesome, submenus, Scroll To, secondary instances, or theme JavaScript. Below is a calm, targeted diagnostic approach that does not involve editing plugin files.

Toggle Bar Does Not Appear

Symptom: the plugin is active, the menu is assigned, but there is no ShiftNav button on the site. Possible causes include the window width being above the breakpoint, the theme not supporting wp_body_open, the toggle bar being hidden by a CSS selector, stale cache serving an old page, or an optimization plugin delaying the required script.

First, reduce the window width below the breakpoint and clear cache. Then check Toggle Bar Injection. If it is set to Header and the theme does not output the required hook, switch it to Footer. If the button appears, record that as a sign of incomplete theme compatibility with the standard hook. After that, check whether your own hide selector is targeting too broad a container. Rollback: restore the previous injection value or temporarily clear the theme-menu hide field.

Two Menus Appear on Mobile

Symptom: the user sees both the theme toggle and the ShiftNav toggle at the same time. The cause is almost always that the theme menu is not hidden in the mobile range or the wrong selector was chosen. Find the real container for the old navigation through the inspector and add it to the hide setting or to theme CSS only for the relevant breakpoint. If UberMenu is involved, check the dedicated Hide UberMenu workflow for UberMenu 3.

Do not hide the entire header. If the logo or cart button disappears, your selector is catching too many elements. The fix is to narrow it down to the specific nav or theme toggle. Validation: below the breakpoint, only one mobile trigger remains; above the breakpoint, the desktop menu returns.

Icons and Arrows Are Missing

Symptom: the menu item text is there, but Font Awesome icons, accordion arrows, or submenu indicators are missing, especially in Firefox. The official FAQ points to CORS restrictions for fonts when CSS or font files are served from another domain, for example through a CDN. Check the browser console for font-loading errors.

The fix depends on your infrastructure. You can exclude ShiftNav Font Awesome from the CDN and serve the files from the primary domain, or configure the Access-Control-Allow-Origin header for fonts. Do not try to patch this by replacing icons with random symbols: the real issue is font asset loading. Rollback: temporarily disable CDN delivery for CSS and fonts and verify that the icons return.

Submenu Items Go to the Wrong Place or Do Not Expand

Symptom: a parent item opens a page instead of expanding a list, the arrow behaves unpredictably, or the user cannot reach the parent page. The cause is usually the wrong submenu type or the wrong role for the parent item. Check the global Submenu Type and the item's individual settings. For a group-only item, you can disable the link; for a real page, it is usually better to keep navigation on the text and expansion on the indicator.

If the menu is complex, do not mix every submenu type without a clear reason. Choose one main mode and add exceptions selectively. Validation: users can clearly tell where to tap to navigate and where to tap to expand.

Scroll To Does Not Reach the Intended Block

Symptom: a menu item should scroll to a form or section, but the action fails, stops too high, or falls back to a standard link. Verify that the selector actually exists on the page: #contact and .contact are different values. ShiftNav documentation states that the value must be a valid jQuery selector. If the element is missing on the current page, the plugin follows the item link and then attempts to find the element after navigation.

If the section hides behind a fixed header, adjust Scroll Offset. If the selector is dynamically generated by a page builder, make sure it remains stable after saving. Rollback: remove Scroll To and keep a regular link until you have a reliable block ID.

The Panel Opens, but Some Items Cannot Be Reached

Symptom: the menu slides out, but a long list does not scroll or lower items get cut off. The cause may be fixed or sticky theme containers, a body wrapper conflict, custom height CSS, or an overly heavy menu structure. Check whether the panel itself can scroll, whether the page background is interfering, and whether the theme forces a fixed height on panel containers.

If the issue happens only with a specific theme, disable your custom menu CSS and test the default skin. If things improve, restore styles gradually. Sometimes the right fix is to shorten the menu, replace always-visible submenus with accordion or shift panels, and remove unnecessary HTML before the menu item list.

Safe Improvements Without Editing Plugin Files

Small improvements can go a long way with ShiftNav Pro as long as they do not interfere with WordPress core, the theme, or plugin files. The key is knowing exactly what you are changing. CSS can improve readability, the PHP API can help with precise placement, and cache settings can resolve conflicts. But every change should be easy to reverse.

Soft Separation of Mobile and Desktop Menus

If the theme does not provide a clean selector for hiding its old mobile navigation, it is sometimes safer to add a small CSS rule in Additional CSS. Use it only after verifying the real class. The example below is generic: replace .theme-mobile-menu with the actual selector from your theme and match the breakpoint to your ShiftNav setting.

@media (max-width: 960px) {
  .theme-mobile-menu {
    display: none;
  }
}

Validation: below 960 pixels, the old mobile toggle disappears, but the logo, cart, search, and other header elements stay in place. Above 960 pixels, the theme's desktop menu continues to work as before. Rollback: remove the CSS and clear cache.

When Code Is Not Necessary

Do not write JavaScript to open and close the panel if the plugin already does that. Do not replace the standard events with your own until you have exhausted the built-in toggle, submenu, and Scroll To settings. Do not add PHP API code just to output a normal main instance: automatic integration exists for exactly that. Code belongs where there is a real condition or a precise insertion point documented by the plugin.

Compatibility with Optimization Plugins

If enabling combined JS causes the menu to open with a delay, do not disable the entire optimization plugin. Identify which ShiftNav files are actually used on the frontend and exclude only those from deferred loading or combination. After every change, clear the site cache, CDN cache, and browser cache. It is important to test not only in an admin session but also in a private window, because logged-in users often see a version of the page that bypasses full caching.

When ShiftNav Pro Is the Right Choice

ShiftNav Pro is a strong choice when mobile navigation is genuinely getting in the user's way and the theme does not provide enough control. Its biggest advantages are a separate off-canvas panel, a clear toggle breakpoint, menu assignment through the WordPress system, Pro submenu types, advanced content support, icons, secondary instances, and developer APIs for precise integration.

Before you download the installation file, define one practical goal: replace a weak theme mobile menu, separate desktop and mobile navigation, build a compact catalog menu, add search to the mobile panel, or create a separate account panel. Without a clear goal, the plugin can easily turn into just another visual layer with little value.

After installation, move from the basics to the details: menu, location, toggle, breakpoint, injection, hiding the old menu, submenus, appearance, advanced content, and testing. That order reduces risk and makes it easier to pinpoint where a problem is coming from. The end result is not just a panel sliding in from the side, but mobile navigation you can explain, test, and maintain.