Summary: Navigation Editor and Block hallway hangout

On October 13, 2021, 10:00 UTC a hallway hangout was held to discuss the future of the Navigation Editor and BlockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience.. See here for the full agenda.

The meeting was convened to discuss some of the challenges contributors have been facing. Those challenges can probably be best dissected into two parts:

1. What important changes to the Navigation Block need to be made for full site editing?
2. What is the best path forwards for the Navigation Editor given the proposed changes to the block?

Meeting recording

Here’s a recording for the full meeting. The recording starts halfway through the introductions and didn’t capture the intros for myself (@talldanwp), Tammie (@karmatosed), Joen (@joen) or Emmanuel (@manooweb).

Topics

The meeting was quite a deep dive into the Navigation Block and Editor, exploring concepts like:

• How the Navigation Editor and Block development has diverged
• Upcoming priorities for the Navigation Block and Editor
• Upcoming improvements to the Navigation Block. Largely centered around the block saving data like a Template Part or Reusable block does (described in the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ issue #34612)
  • There has already been some work on using a Template Part post type for this (pull request #35418)
  • Some exploration should happen around alternatives – a new post type or using the menu term’s description field
  • The actual data structure that is saved needs consideration and exploration
• Migrating menu data when a user switches theme (e.g. to a block-based theme or between block-based themes)
• Backwards compatibility with the current menu system
  • The shortcomings of the current menu / menu item data structure, the overhead and performance of this system
  • The current menu and menu item being the best way to achieve full backwards compatibility in the Navigation Editor
  • MigrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. paths for extensibility
• The navigation block supporting different designs and styles
• Some analysis of products and plugins that handle menus

Outcomes

The main outcome was to focus in the short-term on the Navigation Block for WordPress 5.9. (as an addendum to what was discussed in the meeting, this can be tracked via the Twenty Twenty-Two tracking issue (#75), and in the Navigation Block tracking issue (#35521)).

As the Navigation Block develops it will be possible to explore ways that it might work better within the Navigation Editor.

Immediate tasks

• Publish a clearer set of goals for the Navigation Editor and Block.
• Ensure the tracking issues are up-to-date.