Ability to have different links in the "mobile" menu vs the standard menu.

[jamiemarsland]

Have different Mobile Menu page links vs the main navigation (At the moment the navigation blocks uses the same menu data for all screen sizes)

What problem does this address?

In some circumstances it is useful to have different items in the navigation on "mobile" vs "desktop" screen sizes. Currently this is not possible using the Navigation block

What is your proposed solution?

A means to select different menus to be displayed at different break points.

[annezazu]

@jamiemarsland it sounds like you want a way to conditionally show nav items based on screen size. Is that right? Just want to ensure the description is filled out.

[getdave]

@jamiemarsland it sounds like you want a way to conditionally show nav items based on screen size. Is that right? Just want to ensure the description is filled out.

Jame and I discussed this and yes that is what he's looking for.

Imagine the mobile menu needs to show slightly different items than the primary one. Currently you can't do that.

I do wonder about the a11y implications of this and whether what we actually need is a way to conditionally show/hide blocks depending on screen size. I don't think we'll be able to have different menus tied to the same block.

[jamiemarsland]

This is incredibly important for larger sites e.g ecommerce sites that have mega menus as the main menu.

In the past this was handled by themes by having different menus assigned to different locations.

[getdave]

In the past this was handled by themes by having different menus assigned to different locations.

That's what I'm thinking. Perhaps having two seperate Navigation blocks but with different rules governing the block's display at different breakpoints.

If they are completed different menus then that's pretty valid although I'd like some a11y feedback before we look to implement anything.

[pixolin]

As a workaround :

• Add two menus.
• Define overlay menu "off" for one, "mobile" for the other.
• Give both menu blocks an "additional CSS class" in the advanced pane.
• Add a media query to your custom CSS showing one or the other menu depending on screen size.

---

Kudos to @getdave for providing a little tutorial on Youtube: https://youtu.be/dY3f8sHcAPA

[getdave]

As a workaround :

• Add two menus.
• Define overlay menu "off" for one, "mobile" for the other.
• Give both menu blocks an "additional CSS class" in the advanced pane.
• Add a media query to your custom CSS showing one or the other menu depending on screen size.

Good advice. What you describe here is what we could create as a Core feature without the need for the custom CSS.

[pixolin]

What you describe here is what we could create as a Core feature without the need for the custom CSS.

Only if you provide a setting for a break point, which so far has been different for every theme. Yet this would complicate things. I'm not sure, if wp_is_mobile() is reliable enough.
As a core feature I probably would prefer an extra option for the menu items "show in mobile/show in desktop"?

[aristath]

I'm not sure, if wp_is_mobile() is reliable enough.

It's not. It's notoriously bad... It fails miserably when there is caching involved, reverse proxies and so on.
Jetpack has an improved method (see class-device-detection.php in the Jetpack plugn) but ultimately, any server-side implementation will suffer from caching etc.
Most browsers plan to deprecate user-agents due to privacy concerns so relying on CSS media queries is the safest and simplest method.

[github-actions]

Help us move this issue forward. This issue is being marked stale since it has no activity after 15 days of requesting more information. Please add info requested so we can help move the issue forward. Note: The triage policy is to close stale issues that need more info and no response after 2 weeks.

[getdave]

I've updated the Issue. It's tracked in the Nav block tracking issue and so it's not stale.

[getdave]

Related #43852

[fabiankaegy]

As per the comment from @getdave here: #43852 (comment) This was punted to a future release

[colorful-tones]

Hi folks,
We are only one week away from the Beta 1 cut-off date for WordPress 6.6. This issue hasn’t seen any movement in a while, so we (the editor triage leads of the 6.6 release) have decided to remove it from the WordPress 6.6 Editor Tasks project board.

[getdave]

This Issue is closely related to #39142. There is an argument it can be closed in favour of that Issue.

[getdave]

This issue significantly overlaps with #39142. I trust you won't mind that in the interests of simplicity we close this in favour of the other Issue.