Uncertainities of managing current menus with Navigation Block

[draganescu]

re: #19170

Do we stick to DB structure or Block structure (attributes), or both?

• we could add an opt in flag for the Navigation block, which when set on will sync the two structures (block attributes to the DB menu structure)
• we could simply make the Navigation block use the current DB structure in place of block structure, but that would make this block completely different from all the other core blocks
• we could make a LegacyNavigation block that is used in the nav-menus.php page and uses DB structure for menus
• in either case, one UX issue appears
  • if in FSE one can reuse existing menus ( see Nav block: enable creation from existing WP Menus #18869 ) one will expect that all changes will be reflected back.
    • Also if switching a block based theme to a current theme is seamless, menus should work in both places.

How to implement the Location to Menu relation?

• As long as current themes will exist, menu locations will be a thing
• However in FSE menu locations have no meaning
• We might have a NavigationLocation provider or a HoC or something that is used by the Navigation admin screen so that the concept of "Location" is separate from the Navigation block

Do we need integrating Walkers for compatibility with current menus?

• This is another item that is a conflict between FSE, block based themes and how things work currently. In a FSE context a Walker is not only useless but technically wrong, one should not be able to alter a core block's output for styling reasons.
  • However, if we use the block to manage current menus, then rendering with Walkers is essential because many themes count on that output manipulation to style their menus properly.
• This relates to the problem of "DB structure vs Block structure":
  • only menus saved as DB structure should be rendered through a walker, but those menus are rendered not by the block but by the current WP menu functions which support Walkers already. In this perspective, Navigation block's rendering should not use a Walker because in the context of current themes this block's rendering is not used at all.

What is the best UX for managing large deeply nested menus?

• The current interaction is smooth when the initial content is added but becomes clunky as s menus grow in size and depth. The current abstract UX allows for far easier work with large menus, while the inline editing experience of the Block is quite restrictive.
• The block however already has a tool that is comparable to the current UX, the block navigator.
  • We could use the block navigator in the Navigation block to emulate the current menu management UX. That would add a lot of features to the block navigator, but even at page level all this bird's eye block manipulation would be very beneficial.

What is the UX for "Unassigned menus" management?

• with the nav-menus.php migration people will also still have their countless stale and unassigned menus. There has to be a way to access them in the new screen so one can edit, delete or assign these menus as well.

How to and can we implement programmatic menu management?

• Automatically adding items
  • This will be required not only for new pages, but in general, for example a contact form plugin to add a link to the contact form it created, but from its own plugin management screen. How do we do that with Block structure?
• Extending menus via plugins (to add items, classes etc.)
  • How feasible is this in FSE context?

We need these missing features LinkControl component:

• Links to Categories and Formats
• Store IDs for internal content and full URL for external content
• Restore a page's title to default

Should we think of a deprecation path for certain current features of menus?

• This is very early to ask, but it would help if we imagine the future when:
  • block based themes coexist with current themes
  • menus in WP admin is a block editor using the Navigation block
• Could some features of menus be deprecated?

[wpscholar]

Managing static menus as block template parts in a full site editing context works, but doesn’t provide good options for block based themes nor clarity for end users. A block based theme currently can’t dictate a fallback menu and won’t know enough about the user’s site to hardcode the links. End user’s will have to know what to name the block template parts in order to override any menus provided by the theme, as opposed to just being able to check a box like they do in the current menu system.

What is the intended path for supporting the new navigation block paradigm in block based themes?

[draganescu]

Hi @wpscholar! In the context of Full Site Editing I would say the experience will be better than the abstracted tree view which WordPress currently offers.

Users will be able to work directly with menu entries in the visual context of where the theme suggests menus, but also, using the block, to place any other menus in other template parts. For larger menus, the block navigator will come in very handy, even though there still are plenty of features to be added to it (e.g. drag and drop).

A block based theme currently can’t dictate a fallback menu
Yes, this is interesting. However the navigation block support creating from all top level pages, so a theme could use that (provided the block will offer the option as an API).

This issue is more about the challenges to use the block model to manage the current WordPress menus and compatibility issues between block storage and DB storage of menus.