Nav block use slug to reference Navigation Menu

[getdave]

This Issue specifically tracks the ongoing effort to use a slug to reference a Navigation Menu (wp_navigation Post) instead of the current postID based setup.

This is required because IDs are not consistent across environments. Moreover, it opens the way to improve auto-selection of menus based on location with a site template part hierarchy.

Routes

Currently there are two routes open for exploration:

(Preferred) Key by ID, fetch using existing Data APIs and don't modify REST API

PR: #45443.

This route does not modify the REST API and instead utilises an alternative approach using the existing "collection" endpoint alongside getEntityRecords (plural) to retrieve a Navigation Post by slug.

This route was explored due to push back on the attempt to modify the REST API to handle slugs.

Pros:

• does not require REST API modifications. Retains existing shape.
• likely more consensus between Editor and WP Core contributors.

Cons:

• more complex to implement on the Gutenberg side
• unique identifier as slug but requirement to still key by ID in state introduces complexity
• permissions lookups are delayed until after a Post ID can be retrieved as REST requires ID.

Key by slug and modify REST API to accept slug

PR: #42809.

This route updates the REST API to allow for looking up up menus by slug as the unique identifier.

Pros:

• simpler on Gutenberg side
• fetching permissions works seamlessly as REST API handles slug-based perms lookups.

Cons:

• modifies shape of REST API
• potential backwards compat issues with REST API (although non-identified yet)

[getdave]

Related Issue about the ultimate goal and why we need slugs #56247

[annezazu]

Noting that this came up on a WordPress Freelancer meetup as a current big pain point and blocker for using the site editor.

[getdave]

a current big pain point and blocker for using the site editor.

Thanks for recording this. Let me know if there's anything outside the above recorded reasons as to why this is a blocker.

[conatus]

This is something we are currently really struggling with, despite general embrace of block themes and the site editor.

[fabiankaegy]

Hi all 👋

Just wanted to share a bit of my personal experience with this.

Because of the struggles around using the ID as the connector of Navigation blocks to navigation posts we have actually build a custom version of the navigation block that does exactly what this issue proposes. It uses the slug of the navigation post instead of the ID.

After having used that on several client builds there are a few workflow things that I would say I'm sill not really convinced by which make me believe that using the slug instead of the id isn't actually enough to solve the problems we are facing.

Here are the issues we still run into:

• The navigation posts still don’t automatically exist on all environments just by us referencing the slug. You still have to manually go into every single environment and create a navigation post with that same exact name.
• If you need to change the slug you need to do it on all environments
• One really powerful feature of classic menus was that you could easily create different versions of a menu and then just assign the one you wanted to have to the menu location. With the slug approach you could in theory do the same but you would in that case again cause the template part the navigation is stored in to be modified and therefore pulled from the DB.
• The last point also affects how translation plugins can deal with the navigation

There are some workarounds that we have started to use that do make it less painful but at the end of the day are only light helpers.

Mainly we wrap every navigation block inside a template part. That way we can safely update any settings of the navigation block on every environment individually without causing the main template / template part the navigation block is in to get read from the DB.

---

I know that the Navigation block at one point actually did support the concept of navigation_areas but if I recall correctly that feature was removed from core because of concerns around different themes not supporting the same navigation areas (as they are freeform names). So users switching from one theme to another theme would loose all their assigned navigation menus.

From my perspective that is a true and valid issue that I think we could address differently however. What if we for example did something similar to Figma when a font is not installed.

When a new theme gets activated we could showcase a similar modal which would allow a user to map their navigation menus to the menu locations of the new theme.

[getdave]

Thank you for your insight @fabiankaegy. As I understand it the use case you would like to solve for is something similar to the following:

• you have an existing Navigation Menu in place in your Header Template Part.
• you are likely storing the Template Part in version control.
• you want to swap that Menu but not cause the Template Part to become "dirty" thus get stored in the database. You need the Template Party to remain under version control.
• you would like to be able to create a new Navigation Menu within the Editor and then when ready "assign" it to the Navigation block within your Template Part without modifying that Navigation block.

An example I've used in the past which seems to align with this is a menu that needs to be prepared in advance for some upcoming promotion (e.g. Black Friday). The site owner wants to create a custom menu in advance and then be able to swap it out (perhaps even programmatically via WP Cron or something) on demand.

This certainly feels like a more advanced use case but one I can recognise as being something folk may need.

I believe that if we implement slug as the reference to the Navigation Menu then we can achieve something similar to what you are suggesting if we pair it with using Data Views for Navigation Menus in the Editor.

The workflow would be as follows:

• create Template Part and add a Navigation block with a slug attribute of primary (this can be named whatever you'd like).
• create a menu with the matching slug via the Navigation block
• store the resulting markup in version control.
• when it comes time you create a new Menu (perhaps by adding a Nav block to a new Post or just doing it on a Staging environment).
• you name the new Navigation Menu something like primary-draft-2 (whatever naming convention is required).
• when it comes time to swap out the menus you use dataviews to:
  • rename the existing primary menu to primary-old
  • rename the new menu to primary
• because the Nav block is referencing primary it will then render your new menu automatically without any changes to the template

I appreciate this is a more cumbersome workflow, but the alternative is to expose potentially complex concepts such as "Navigation Areas" to less experienced users which would require them to keep track of even more information. @mtias provided more context about this here.

I think we should try and finalise the work on moving to slugs (which also has value as a standalone task) whilst also utilising Data Views for Navigation Menu CPT management. That way we get all the data manipulation powers of Data Views for free which could allow you to achieve your workflow within the Editor.

What do you think? Is there anything I missed?