Navigation Areas are overly complex

[getdave]

Having spent some time with Navigation Areas there is a concern that the concepts and UX we have introduced are going to be too complex.

In an informal discussion @mtias shared his concerns which I've attempted to summarise below along with a potential solution that he proposed.

Summary

The main problems are:

• Navigation Areas are mirroring a concept ("Menu Locations") that exists for classic Themes but which has less value in a world of block themes and global styles.
• The UX around Navigation Areas + Nav blocks + Nav CPTs is very confusing.

In the world of classic Themes, users switch themes in order to get new styles and visual appearance. In this world we have Menu Locations to try and allow us to map Menus from Theme to Theme. However, in practice this rarely works and the whole concept of Menu Locations has always been challenging for users to grasp.

In the world of block Themes, global styles will make it less likely users will need to switch Themes. After all colors, typography and more can be modified within any block Theme. Moreover you have near limitless layout flexible afforded via the block library in the Editor.

Whilst it is desirable to preserve menus when switching Themes, trying to use Navigation Areas to map the concept of "locations" into the block based world of the editor is not producing a great result. Indeed, it is bringing over concepts from the classic world that may no longer need to existexist. It is also producing a sub-optimal UX which requires the users to understand a number of complex concepts.

What is your the proposed solution?

Matias is proposing we retain the existing system of saving Navigation to a Custom Post Type. Decoupling presentation from data is a good idea. But...

Instead of burdening users with the concept of areas and locations, we should remove Navigation Areas and instead attempt to use a heuristic to automatically pick the correct Navigation CPT for a given Navigation block based on it's location within a template.

For example, imagine you insert a Navigation block into your Header Template Part on the Index template. That Navigation block should be automatically named as header-index-navigation. You then create some Nav items. This should create a Navigation CPT which a matching slug of header-index-navigation. This creates an implicit relationship between the block and its data via the slug.

Now in another Theme (let's called it B), the theme author has undertaken a similar exercise and therefore their header.html template part contains a Navigation block which has a slug reference of header-index-navigation (again this is based on it's template + template part location).

If I switch to Theme B then the Navigation block will attempt to look up Navigation CPTs with a slug matching header-index-navigation. As I created such a CPT in Theme A, the Nav block from Theme B will be able to pull through the correct navigation items by matching against the slug.

If there is no match then the Nav Block should fall back to a default output on the front end (Page List?), whilst within the editor a notice should be displayed prompting the user to resolve the Navigation block to select which menu they wish to display. It is key that the block should always output something sensible on the front end, but within the editor it is ok to prompt the user to take action.

This isn't a fully automated solution but it covers the 80% use case whilst also greatly simplifying the UX experience for users and authors within the Editor.

What do we think about this approach?

[talldan]

For example, imagine you insert a Navigation block into your Header Template Part on the Index template. That Navigation block should be automatically named as header-index-navigation. You then create some Nav items. This should create a Navigation CPT which a matching slug of header-index-navigation. This creates an implicit relationship between the block and its data via the slug.

I had the same idea about using a slug to represent the location, but discounted it. The reason is that it prevents the reusability of menus. My CPT has an implicit relationship to where it's rendered and that's not beneficial. If I want to use the same CPT in my footer, what's the solution? Can the CPT have two slugs?

Instead of burdening users with the concept of areas and locations, we should remove Navigation Areas and instead attempt to use a heuristic to automatically pick the correct Navigation CPT for a given Navigation block based on it's location within a template.

This is what I originally wanted, to use the concept of Template Areas for the value of a location (#35750 (comment)) and to keep the area concept implicit to the nav block and not introduce another block (#36087 (comment)).

As mentioned above though, I don't think a slug will work, the CPT should be fully decoupled from where it is rendered to ensure menu reusability.

I personally think the technical concept of areas can be kept, but we limit the amount of user interaction required by automatically using the parent template part area as the value (e.g. Header, Footer).

[draganescu]

imagine you insert a Navigation block into your Header Template Part on the Index template. That Navigation block should be automatically named as header-index-navigation. You then create some Nav items. This should create a Navigation CPT which a matching slug of header-index-navigation. This creates an implicit relationship between the block and its data via the slug.

Isn't that an explicit relationship if the block and the CPT share a string that links them?
Also what happens when the user creates more menus using the same block that has this single slug form? Do we increment them?

their header.html template part contains a Navigation block which has a slug reference of header-index-navigation

Should a theme author code in the slug? Since we infer this from the tree of parent blocks that should not be needed.

[adamziel]

Great questions @draganescu and @talldan! I think the concept of slugs addresses these specific problems, but let's keep going – I'm just as curious as you.

If I want to use the same CPT in my footer, what's the solution? Can the CPT have two slugs?

It's the same as with numerical IDs. You'd just have two navigation blocks referring to the same slug.

Isn't that an explicit relationship if the block and the CPT share a string that links them?

Implicit/explicit thing is debatable. When you add a new navigation block in the header, it takes a slug like header by default. When you move it to the footer, it keeps referring to the same slug. You can choose a different menu to display.

Also what happens when the user creates more menus using the same block that has this single slug form? Do we increment them?

Yes, like header-2. Or we could default to the same header slug and enable users to choose a different menu.

Should a theme author code in the slug? Since we infer this from the tree of parent blocks that should not be needed.

Perhaps initially. Ideally they wouldn't have to. Perhaps a template part could provide that info through context?

[talldan]

It's the same as with numerical IDs. You'd just have two navigation blocks referring to the same slug.

So I have a slug header-index-navigation in my header, and header-index-navigation in my footer. How does this help my menu data transfer correctly when switching themes or inserting a new footer pattern/template area? It seems like the new footer will be expecting a slug of footer-index-navigation.

[adamziel]

So I have a slug header-index-navigation in my header, and header-index-navigation in my footer. How does this help my menu data transfer correctly when switching themes ​or inserting a new footer pattern/template area? It seems like the new footer will be expecting a slug of footer-index-navigation.

It doesn't. Only the header navigation would transfer correctly and the footer one would require a manual intervention. I believe @mtias's argument is that:

• A fully automated transfer would have shortcomings anyway
• This is a larger FSE problem that would require a kind of "conflict resolution" feature in a future WP version
• Instead of automating as much as possible today, let's acknowledge that FSE will evolve tomorrow and trade off certain shortcomings for a cohesive feature base that will play nicely with things like template hierarchy

Did I get it right @mtias? Would you like to speak more about that?

[talldan]

Instead of automating as much as possible today, let's acknowledge that FSE will evolve tomorrow and trade off certain shortcomings for a cohesive feature base that will play nicely with things like template hierarchy

This is information that I personally am unaware of, the constraints here need to be made clearer so that developers can make better decisions.

[getdave]

Dan I think this was my biggest take away. My (previous) understanding was that we needed a hands-free solution that would work automatically in all cases without user intervention.

What I'm hearing now is that it's acceptable to require manual intervention (in the Editor) if the front end (of the site) shows a sensible / practical fallback.

The overall thread is now:

• Theme switching will become less of a concern over time due to Global Styles.
• We need to reduce need for users to understand the concept of locations.
• We must reduce the complexity of UI/UX (Nav Areas...etc).
• Make a best guess based on heuristics around template location.
• Have sensible fallbacks in place and allow for manual user conflict resolution within editor.

[talldan]

I don't think any of that means that encoding information in a slug is the best solution.

It is absolutely possible to achieve all of that, but still keep the wp_navigation decoupled from the block. The answer would be to continue using site options as a map from template part area to menu id. That's the solution I actually wanted from the start (#35750 (comment)).

So I think there's still context that's missing around why a slug is best.

[getdave]

I don't think any of that means that encoding information in a slug is the best solution.

I agree. I'm not advocating for slugs.

keep the wp_navigation decoupled from the block

This sounds like a good objective.

The answer would be to continue using site options as a map from template part area to menu id. That's the solution I actually wanted from the start (#35750 (comment)).

How easy is it to explore this?

Lastly - should we prepare a revert PR for Navigation Areas in case none of this comes to fruition in time? I'm not clear on the protocol.

[mtias]

If I want to use the same CPT in my footer, what's the solution? Can the CPT have two slugs?

In that case you'd just reference the one that's already created since you want it to be reusable.

As mentioned above though, I don't think a slug will work, the CPT should be fully decoupled from where it is rendered to ensure menu reusability.

It's not about decoupling, it's about not forcing a user to name and deal with an abstraction when it's not necessary. The place where a user first creates a menu carries enough contextual meaning to handle the naming we need for the CPT.

When a user is inserting a new navigation block, it's the block the one that should display if an existing menu is present to reuse. We can use semantic areas to automatically load the menu data from a corresponding area if there's one present (header, footer, etc).

Also what happens when the user creates more menus using the same block that has this single slug form? Do we increment them?

Yes, but it's also a bit of an abstract thought. If someone is creating a different menu for a header, it's almost a requirement that they'd also have a different template part in place (say, for a different header in an archive) so the menu created there would inherit that difference in name already.

Should a theme author code in the slug? Since we infer this from the tree of parent blocks that should not be needed.

Agreed, the more we can leave to "it just works" based on the presence of template areas, the better.

How does this help my menu data transfer correctly when switching themes or inserting a new footer pattern/template area?

A user / theme should be able to set a menu that was created in a different area (header) in the footer, and it'd be clear the data is coming from the menu in the header. If the user wants to have a different menu data in the footer they'd create a new one or delete the data coupling.

[mtias]

Writing some aims down in case it helps contextualize things:

• Keep nested structures as lean as possible. "Menu areas" are adding an extra layer of nesting that we should aim to reduce.
• The footprint of a block should be easy to read and align with the rest of the block library.
  • Instead of wp:navigation {"navigationMenuId":8035} align with template parts in wp:navigation {"slug":"header-menu"} or reusable blocks with {"ref":8035}.
• Naming should not be a task we require users to do when we have a context that's already named. We are essentially saying "this is the menu on your header". We should attempt to take this as far as we can because it's a new paradigm we have in front of us.
  • For example, whenever you insert a navigation block in a header, we can automatically use the CPT data from any header- menu if there is one. That could make things feel magical and also service theme switching by having meaningful fallbacks that are not reliant on a convention of "primary", etc. A user would always be able to start fresh if they don't want, but something to think about.
  • In this context, maybe a slug is not needed at all unless a data menu is being specifically targeted. (i.e a header-menu will be loaded first, a header-menu-2 would need to be explicitly added in the block attribute as a reference.)
• When a menu has inner blocks that are not just links we should consider not saving to a CPT at all and just rendering in the container template (like navigation patterns). The reason for this is we should align the impetus of the "light navigation" with the reality that when a navigation has more elements it blurs the line of data and presentation: "mega menus" are not expected to be reusable as is in a header and footer because their display is fairly opinionated.

[talldan]

In that case you'd just reference the one that's already created since you want it to be reusable.

Though as mentioned it does break with the idea of the slug being connected to the area. I would now have a header slug in my footer area. Some of the other behaviors that you describe, like automatically loading the correct menu when a new navigation block is inserted in a footer now won't work reliably.

It seems like a constraint that will be hard to solve, which is a shame as we already have another system that can (I think) do everything you describe. That would be to store the template area and menu relationship in a database table. The only part that's difficult here is handling multiple menus in the same area, but I think there's also the same challenge with slugs.

@adamziel also mentioned the idea of a conflict resolution UI for a user. The problem here is that until the user resolves this conflict, menus are not being shown on the front-end of a user's site. My feeling is that if we can do better than that, we should.

[getdave]

The problem here is that until the user resolves this conflict, menus are not being shown on the front-end of a user's site.

I mentioned above and in the issue description that if a block requires resolution within the editor, the front of the site should always show something. We need a good default fallback for the front end. Something like listing the site's top 6 pages for example.

[noisysocks]

Can I suggest we revert Navigation Areas for WP 5.9 (#36604) and then explore this problem of how to automatically select a Navigation during a theme switch in the Gutenberg plugin for WP 6.0? It feels to me that some iteration is needed, more than we ought to do in a week, and that it's not a huge problem if WP 5.9 ships with the limitation of having to manually choose a Navigation again after switching theme.

[getdave]

Can I suggest we revert Navigation Areas for WP 5.9 (#36604) and then explore this problem of how to automatically select a Navigation during a theme switch in the Gutenberg plugin for WP 6.0? It feels to me that some iteration is needed, more than we ought to do in a week, and that it's not a huge problem if WP 5.9 ships with the limitation of having to manually choose a Navigation again after switching theme.

I agree with this. Having used the feature for a good week or so, I don't think it provides a good enough user experience. It's too complex and requires the user to understand too many concepts.

I think we should merge @adamziel's revert PR and look to address the concept of preserving Nav on theme switch in the 6.0 cycle when we have more time to provide a more considered approach. It will also afford more time for extenders to test any approach we do come up with.

I appreciate all the work that has gone into Nav Areas so I don't say this lightly but the priority should be ensuring we have a well considered feature for WP.

If anyone disagrees with this then please say so.

[spacedmonkey]

I have never really understood why navigation areas are needed. We already have menu locations, navigation areas feel very very similar. We could reuse those, instead of reinventing the wheel with this new watch of locating mechanism.

What do we think of finding way to pin a menu block to a location? I would like to explore this idea more, so I believe that navigation areas should be reverted for now and introduced ( if needed ) in WP 6.0.

[adamziel]

How would you connect the concept of a menu location, which is in a fixed place in classic themes, to block themes where nothing is fixed and users can create virtually any layout?

[annezazu]

Can this be closed since Navigation areas weren't pursued?

[getdave]

As Navigation Areas were deprecated we can safely close this one out.

[getdave]

FYI I came back to this after a while trying to recall why we chose to deprecate the concept of Navigation Areas. I got AI to do a summary for me

Navigation Areas were deprecated in 2021 because they added complexity, confused users, and did not align with the block editor's paradigm, leading to their reversion in favor of simpler, heuristic-based solutions for associating navigation menus with templates.

---

There's also a longer summary of the above discussion

1. Reasons for Deprecation:

   • Navigation Areas, introduced as an adaptation of classic theme "Menu Locations," conflicted with the goals of block-based editing and were removed in 2021.
   • The rigid system didn't fit the flexibility offered by block templates and global styles, prompting a shift away from explicit location definitions.

2. Concerns Raised:

   • Complexity: The Navigation Areas concept added unnecessary layers to managing navigation blocks and CPTs.
   • User Confusion: Managing Navigation Areas, especially during theme switching, proved unintuitive for users.
   • Mismatch with Block Editor Paradigm: This approach carried over classic theme structures, which contradicted the vision for block editing.

3. Proposed Alternatives:

   • Use heuristic rules to link Navigation CPTs with their location in templates (e.g., naming conventions like header-index-navigation).
   • Store relationships implicitly, based on block placement, avoiding explicit "Navigation Area" slugs or identifiers.
   • Simplify UX by focusing on fallback systems, such as rendering a default page list when data cannot be resolved automatically.

4. Outcome in 2021:

   • Navigation Areas were removed for WordPress 5.9, with improvements to be iteratively explored for future versions (e.g., WordPress 6.0).
   • Focus shifted to refining navigation workflows without reintroducing redundant structures.

5. Key Discussions and References:

   • [#35750](Navigation block - preserve navigation block data on theme switching #35750) - Heuristic-based area concept.
   • [#36522]([Try] menuSlug instead of navigationMenuId #36522) - Menu slug approach.
   • [#36604](Rollback navigation areas #36604) - Proposal and decision to revert Navigation Areas for WordPress 5.9.