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.