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)