The future of the block-nav-menus theme opt-in for the Navigation Screen

[talldan]

#24503 introduced the concept of the theme opt-in to the navigation screen.

This opt-in is a way for the theme to declare that it supports styles for a wider range of blocks in a menu. Once this is active, more block types are supported by the navigation screen. In the front-end, menus are rendered using the block markup, instead of the markup produced by the core wp_nav_menu function.

Since most of the development has been based around building a good foundation for the navigation screen, the feature hasn't had much focus. There are several aspects that could be improved.

Improvements

Saving menus

When the theme opt-in is active, the navigation screen still coverts blocks into the old menu item format when saving. This has a few consequences:

• None of the more advanced features of the navigation block itself are supported (e.g. colours, submenu indicators, spacing), since this information can't be saved
• It's possible for a user to go back to the old menu screen and re-arrange blocks into an invalid structure (e.g. a link as a child of a search block)
• The code for rendering menus is much more complicated, and involves hooking into wp_nav_menu and converting menus to blocks

Possible solution: investigate options for saving the entire navigation block in its usual HTML format when the theme opt-in is active.

edit: This could incorporate the editor using the same storage for the block as outlined in #34612 (template part / custom post type).

Visual editing and theme styles

By default the navigation editor has an accordion style appearance, which is somewhat different to the usual appearance of the navigation block.

When a theme has opted-in, it should be possible for the user to achieve anything with their menu that they could achieve in the post or site editor. The user should be able to edit a menu that's a more accurate representation of the front-end of their site.

Furthermore, it could also be possible for themes to provide editor styles for menu locations.

Migrating between themes

Whatever approach is taken, users should be able to migrate menus between themes that may or may not have the theme opt-in.

The immediate future

The navigation editor is approaching a reasonable level of stability, and it'd be good to consider removing the experimental flag in the Gutenberg plugin, or making it opt-out instead of opt-in. Given the theme opt-in still needs a fair amount of work, it could be an idea to consider making this part of the screen experimental while it's being developed.

[draganescu]

Excellent perspective @talldan! I also think for the immediate future we should consider lowering the focus on this opt in, at least until the standard classic WordPress menus are solved by the block navigation editor.

For opt-in improvements:

• Big ➕ for saving the block HTML as is, it's pointless to lose features
• Switching themes with and without opt-in should result IMO in data preservation, and a lossy convert to classic menu option
• editor styles for menu locations would be awesome

[getdave]

For the purposes of removing the "experimental" status on the Navigation Editor, we agreed we would disable the theme opt-in from the screen until core developers have had enough time to improve the feature. That means no additional blocks.

Can we reframe this issue around that or create a new issue?

[talldan]

New issue sounds good. I see #34265 was created, thanks @getdave!

[talldan]

Migrating between themes
Whatever approach is taken, users should be able to migrate menus between themes that may or may not have the theme opt-in.

Thinking some more on this, a fundamental factor of any migration would be to prevent data loss for the user.

I've been thinking that it might be preferable to leave the user's data completely in-tact.

Each menu could have a type of either 'classic' or 'block-based':

• Existing menus are classic menus that would be backward compatible (as much as possible) and always render using the current walker.
• An optional new menu type is a 'block-based' menu that would support a full navigation block and use block rendering.

If the user switches to a theme with a theme opt-in, the user is given the option to convert a classic menu to a block-based menu. But rather than overwrite their existing menu data, a new menu with the 'block-based' type is created from the 'classic' menu, and the 'classic' menu is retained. This gives the user safety in always being able to switch back to their old menu, but also allows experimentation with blocks.

If a user switches back to a theme that doesn't have the opt-in, they can safely re-assign their classic menus to the menu locations.

[getdave]

This opt-in is a way for the theme to declare that it supports styles for a wider range of blocks in a menu

I understood this opt in was for the Theme to use block rendering as opposed to Walkers. The support for additional blocks was a nice side effect. This is as per the Nav Editor README docs. Can you confirm?

[getdave]

Related #34612

[talldan]

I understood this opt in was for the Theme to use block rendering as opposed to Walkers. The support for additional blocks was a nice side effect. This is as per the Nav Editor README docs. Can you confirm?

It does currently render a nav block:
https://github.com/WordPress/gutenberg/pull/24503/files#diff-68aa3e914d52bce59d8cfcac6c7a10cad3bb8dca6021d00be35bdf546a6ea161R313

But the reason for this feature is to increase the number of blocks available to users that are using non-block based themes. Using navigation block rendering is the means to achieve that. The walker can't arbitrarily support blocks because the resultant HTML is too inflexible (every block would need to be in an <li> element).

But the way the theme opt-in currently works has some downsides. The nav block itself has no attributes (because there's nowhere to store them), so lots of nav block functionality is actually missing:
https://github.com/WordPress/gutenberg/pull/24503/files#diff-68aa3e914d52bce59d8cfcac6c7a10cad3bb8dca6021d00be35bdf546a6ea161R304

So I think there's a good reason to reconsider using menu items for storing blocks when a theme opt in is active. Using a custom post type like expressed in #34612 could be a good alternative.

[getdave]

FYI off the back of the discussion above I'm updating the Nav Editor docs to correct inconsistencies #34682

[Thelmachido]

Closing this issue due to the project being moved to an inactive status on the feature projects page in coordination with the project leads. If this work is picked back up, issues can be revisited and reopened as needed.