Navigation Editor Tracking Issue

[draganescu]

Last updated Aug 23, 2021

Extends #24551, preliminary for milestone 7
This is an overview issue that we'll maintain going forward into WP 5.7 and 5.8 milestones. It attempts to track discussions and resulting actions about the Navigation Editor.

This overview tries not to track bugs of the Navigation Editor - for that you should filter open issues using the labels:

• [Feature] Navigation Screen
• [Type] Bug.

🏷 High

This high priority label designates what is required before we can remove the "experimental" flag in Gutenberg from the Nav Editor screen. The prerequisite for doing this is: UI/UX feature parity with the existing Menus screen (nav-menus.php).

UI/Visual Issues

Issues that are important to ensure the quality of the use experience is at an acceptable baseline:

• Add accordion style menus to the navigation block #29747 - fix the current UI styling inconsistencies.
• Improve how different types of nav items are rendered on the Navigation screen #34035
• Width of long items affect other items on the Navigation editor screen #34036
• Fix spacing issues in the mobile version of the Navigation editor screen #34032
• Fix snackbar component overflow on mobile on the Navigation editor screen #31182
• Fix error notice appearing underneath the modal screen overlay on the Navigation editor screen #31100
• Navigation Screen: consolidate top bar with the one used in the FSE #31241

Detrimental to UX

Issues deemed critical that severely impair the user experience of the new screen:

• Handle heavily nested items in the Nav Editor screen #23583 (comment) - need to be able to click to expand all levels of nesting via some means. Possibly requires a dedicated Issue.
• Nav Editor menu title doesn't support special characters #34223
• Temporarily disable support for theme-opt for block-nav-menus from the Nav Editor #34265
• Improve Nav Editor placeholder state #23953
• Nav item toolbar too far removed from nav item block #34225
• Improve UX for nesting navigation items via drag / drop #34234
• Make it easier to add new items in between existing Nav Item blocks within the Nav Editor #34268
• Show more items in the "Recent" items of the Link UI when adding a new Nav item in the Nav Editor #34283
• Add block inserter to navigation editor #34438

Feature parity with the classic navigation screen

Issues required to achieve a feature parity with the existing screen:

• Option to bulk add entities of any type in Nav Editor screen #31667
• "Manage Locations" doesn't work on the Navigation screen #33815
• Mark invalid menu items in Navigation editor and block #23573
• Expose user facing documentation on the Navigation Editor screen #34266
• Add support for custom post types in navigation editor #34440
• Add support for custom taxonomies in navigation editor #34442
• Navigation editor should respect show_in_nav_menus  #34443

---

🏷 Normal

User experience

• Confusing navigation block inserter menu / block library #33867
• Add all pages option doesn't work in Navigation screen #33999
• Nav items of fixed "type" retain ability to enter a custom URL. #34224
• Navigation editor: Menu switcher doesn't show after deleting a menu #34255
• Add ability to create a new navigaition menu with a single click #34227
• Pass filter value when clicking Browse All in Nav Editor screen #34987

Visual/UI

• Improve responsiveness of the navigation screen #29100

Improved interaction mode

• Navigation Editor: Preview functionality #31074
• Navigation Editor: Add visual cues for the menu and page list items #30659
• Navigation Screen: Always show appender #31276
• Navigation Editor: Handling saving for multiple menus #31813
• Navigation screen: can't move links into a submenu with keyboard only #33271
• Navigation screen: blocks can't be dragged into submenus #33272

Feature parity with the classic navigation screen

• Load last edited menu by default #22623
• Ability to ascertain nav item "type" without having to select each Nav item #34233
• Ability to bulk select non (immediately) adjacent sibling Nav items #34232

Compatibility with the Navigation block

• Provide a better way to disable/enable nav block features for the nav editor #30007
• Decide if it's better to switch to a Legacy Menu block (TL;DR - decision was it's best to evolve the existing Nav Block to suite the needs of the editor).
• Improve Nav Editor placeholder state #23953
• List View Design Updates #24029
• Handle heavily nested items in the Nav Editor screen #23583
• Allow expanding and collapsing of nested blocks in List View #26141
• Supporting future block types in the navigation editor. #30006

Required REST API updates

• Migrating experimental navigation and widgets screen to bulk REST API #24907
• REST API: Introduce reorder menu endpoint #25093
• REST API: Audit menus endpoint slashing #25094
• REST API: Audit menus route filters. #25095
• Navigation: Preload API requests #24642
• Add preload_paths filter for widgets screen and full site editing #28701
• Navigation editor: Nested block-based menu items are deleted and re-created on each save #35047
• Navigation editor: Speed issues with saving and loading #35046
• Navigation editor: Fail loudly when attempting to save unsupported blocks #35045
• Lots of calls to menu item REST API after saving menu.  #34999

Upgrading WordPress menus to allow blocks

• Navigation: Make the block-nav-menus setting more granular #24638
• Navigation Screen: Page List block styling is inconsistent with navigation link styling #29101
• Navigation Screen: Page List block styling is inconsistent with navigation link styling #29101
• Navigation: Improve how non-link blocks appear in old nav-menus.php screen #24639

Customizer support

This may evolve into a lot more once we have the foundation for embedding a block editor in the customizer.

• Navigation: Add new block-based screen to Customizer #24844

Others

• Remove duplicated blockToMenuItem function #35037

---

🏗 Architecture

This section is reserved for Issues that are related to overall architectural discussions. Any concrete tasks should be added to the relevant section above.

• The future of the block-nav-menus theme opt-in for the Navigation Screen #33969
• Navigation Block: save data to a custom post type #34612
• Provide a better way to disable/enable nav block features for the nav editor #30007
• Experiment: dedicated menu and menu item blocks for navigation editor #34496

---

Known/Potential backwards compatibility problems

This section is reserved to list any potential or known backwards compatibility issues with the existing Menus screen that cannot (or will not) be solved in time for removal of the Experimental status from the Nav Editor. It is expected that we will communicate early about these problems in order that developers have sufficient time to adapt their code.

• Navigation Screen: Menu item custom ACF options #31551

[draganescu]

Updated and deprioritized a couple of issues.

[javierarce]

I'm reviewing the navigation issues & enhancements, and here are some tickets that don't appear in the list above:

• Supporting future block types in the navigation editor. #30006
• Fix error notice appearing underneath the modal screen overlay on the Navigation editor screen #31100
• Fix snackbar component overflow on mobile on the Navigation editor screen #31182
• Navigation Screen: Always show appender #31276
• Option to bulk add entities of any type in Nav Editor screen #31667
• Navigation Editor: Handling saving for multiple menus #31813
• Navigation screen: can't move links into a submenu with keyboard only #33271
• Navigation screen: blocks can't be dragged into submenus #33272

[getdave]

I've moved all the items from @javierarce's list that are not Type: Bug into the most appropriate places I could find.

Note this Issue's tasks are going to be re-prioritised in the near future. I will update here regarding when and where that will happen.

[getdave]

Update - 2021-08-11

• Work has continued on bug fixes and stability.
• Looking to define what is required to bring the Nav Editor out of "experimental".
• To this end, the team is looking to arrange a hallway hangout (or similarly public forum) to compare/contrast the classic navigation screen with the block-based navigation screen.
• We're also looking to filter out or break down any "Epic" Issues into more actionable tasks (where possible).
• @javierarce has also been looking into and documenting the need to add some "polish" to the Nav Editor screen in order that UX bugs/issues don't spoil the overall experience. I believe he will look to add these as Bugs to the repo soon.
• From this we will then look to reprioritise the task list in this tracking Issue around achieving feature parity at a user interface level (developer APIs will follow).

[javierarce]

Here are the last three issues I've recently created related to the editor. The first one is the most important and probably key to have a nice experience creating menus.

• Improve how different types of nav items are rendered on the Navigation screen #34035
• Width of long items affect other items on the Navigation editor screen #34036
• Fix spacing issues in the mobile version of the Navigation editor screen #34032

I've added them (plus others from my previous message) to the original post on top. The only issue I see that is not categorized is:

• Supporting future block types in the navigation editor. #30006

[getdave]

I've added / moved all of the visual items raised by @javierarce to the High priority section. These are the minimum baseline visual inconsistencies that need to be resolved prior to the screen coming out of "experimental".

The only issue I see that is not categorized is #30006.

This is the issue regarding supporting future block types. I'd say that's beyond the scope of what is required to get the Nav Editor out of "experimental". However I will add to one of the lower priority sections.

[getdave]

Update - 2021-08-25

• The team have been focused on reforming the project around the goal of removing the "experimental" status of the feature within the Gutenberg Plugin (only).
• Held a Hallway Hangout on Tuesday to compare and contrast Navigation screens and determine next steps.
• A summary will be posted shortly A summary of the meeting and decisions made is available.
• Tracking issue is being updated to focus on the tasks required to remove "experimental".
• Work is continuing on exploring wider architectural issues such as how to best make use of the Navigation block whilst retaining stability.
• We've continued with small UI/UX fixes.

[talldan]

Update - 2021-09-01

• A plan has been formed for migrating from the customize API to the REST API in the navigation editor. The editor has been temporarily using the customize API for saving menus while some REST API design issues were resolved (see: REST API: Introduce reorder menu endpoint #25093)
• The navigation editor header has been refreshed to more closely match the styles used by other editors (see: Update navigation screen topbar #34166).
• Some early discussions have taken place in the #feature-navigation-block-editor slack channel about extensibility in the navigation screen. Join the discussion if that's a topic you're interested in (see: https://wordpress.slack.com/archives/C01KDAZJMQ9/p1630160027012100).

Smaller fixes and enhancements

• The navigation block is due to support a new block type, the 'Submenu' block, and work has been undertaken to ensure the navigation editor supports this (see: Update navigation editor to support new submenu block #34281).
• The above change also fixes many of the block styling issues in the navigation editor.
• A fix for the entities being shown in menu names was merged (see Navigation Screen: Decode entities in the menu names #34263)
• Loading of the navigation screen has been optimized by preloading API requests (see Preload menu REST API requests on new navigation editor. #34364)

[kellychoffman]

I did a review and noted UX items that should be addressed before we can move this out of experimental phase: (Will link them all up to issues)

• "Switch menu" location is out of context from the current menu you are editing. We have solved this similar issue in template editor with a dropdown next to the name of the template you are on - we should reuse this UX.
• Once you add a menu, the state of the block shows placeholder bars and you are blocked as to what to do next. Ideally, we skip this step and go right to add Existing Page, Add All Pages, Start Empty. (This layout is also currently broken and needs a bit of a refresh.)
• “Add new page” label is unclear - the key word to this setting is "Automatically" and that is only shown in the descriptor text. Let's move it to the label so it reads: "Add new pages automatically"
• No undo button - Is there a way to undo changes?
• When adding all links I have to know to "Convert to links". This should either be automatic or more obvious.
• Manage locations button placement - is confusing in context and should be separated from the task of applying this menu to certain locations provided by the theme. (Current implementation has it hidden behind a tab.)
• Adding pages, whether one at a time or several at once needs some further iteration Split control for URL and Text within Link UI #33849
• How can I see how this looks? Or apply different layouts/styles? ('View theme styles' similar to Widgets could be an MVP of this)
• Usage of "Menu" vs. "Navigation" terms feel a bit confusing. Not clear why we are using them + where.

cc @javierarce

[getdave]

Thanks @kellychoffman. Great to have some additional eyes on this ✨

For the purposes of ensuring the list of "Todo" items is actionable, it would be super helpful if we can:

• ensure all the Issues raised are specific / immediately actionable.
• dedupe them against existing Issues.
• add them to the appropriate place under the High section.

that should be addressed before we can move this out of experimental phase

As I'm sure you're aware, it's very easy for this list of "priority" items to grow indefinitely so I'm hopeful we can prune these back to the items that are absolutely essential for removing the "experimental" flag 🙏.

For context, the general agreement in the Hallway Hangout was that we would focus on items that are clearly and obviously detrimental to the UX in terms of being able to create a basic menu. Optimisations and ideal flows will be addressed in follow up phases.

Open to discussion however - how do others feel?

Thanks again @kellychoffman 🙇‍♂️

[talldan]

A lot of these are I think covered already, but maybe some things are missing from the tracking issue:

"Switch menu" location is out of context from the current menu you are editing. We have solved this similar issue in template editor with a dropdown next to the name of the template you are on - we should reuse this UX.

Covered in #31241, but this isn't part of the tracking issue.

Once you add a menu, the state of the block shows placeholder bars and you are blocked as to what to do next. Ideally, we skip this step and go right to add Existing Page, Add All Pages, Start Empty. (This layout is also currently broken and needs a bit of a refresh.)

Covered in #23953, already high priority

“Add new page” label is unclear - the key word to this setting is "Automatically" and that is only shown in the descriptor text. Let's move it to the label so it reads: "Add new pages automatically"

Good feedback, lets address this. Could be a Good First Issue.

No undo button - Is there a way to undo changes?

Also part of #31241. This is a quick win, so I've gone ahead and made the change in #34533

When adding all links I have to know to "Convert to links". This should either be automatic or more obvious.

This 'Convert to links' UI will be removed, the current behavior is a bug introduced from the nav block. (#23953, #33999)

Manage locations button placement - is confusing in context and should be separated from the task of applying this menu to certain locations provided by the theme. (Current implementation has it hidden behind a tab.)

There's some related discussion on #33815, where I've mentioned this. Would be great to see some options for improving this.

Adding pages, whether one at a time or several at once needs some further iteration Split control for URL and Text within Link UI #33849

Seems to already be in progress, but not part of the tracking issue. At the moment there are a few issues around adding items, so I do agree the process could be revisited, but not sure I agree it's a blocker for opening up the editor in the plugin, but definitely something to address before this lands in WordPress core.

How can I see how this looks? Or apply different layouts/styles? ('View theme styles' similar to Widgets could be an MVP of this)

This isn't possible right now, it will most likely be a longer term goal as part of integrating the customizer. The widgets screen has the same issue, but was still launched, so I don't think this is a blocker to removing the experimental flag.

Usage of "Menu" vs. "Navigation" terms feel a bit confusing. Not clear why we are using them + where.

Agree, it'd be good to have an issue for this and some guidance. I think this has come about because the navigation block is being used to edit classic menus.

[Mamaduka]

The #34224 issue is listed in both High and Normal priority lists.

[javierarce]

Thanks for the review, @kellychoffman!

Regarding "How can I see how this looks? Or apply different layouts/styles?", I'd like to point out this exploration I did some time ago:

• Navigation Editor: Preview functionality #31074

[getdave]

Update - 2021-09-08

• Everyone is focused on addressing the High priority issues on the Tracking Issue (see above).
• Work has continued on the Submenu block and preparing it ready for use in the Nav Editor.
• The navigation editor header has gained more tools to better match other editors - props to @talldan for all his work here.
• Work is underway to add a global inserter to the screen.
• The creation flow for navigation menus was improved with a new block placeholder
• Improvements to List View drag and drop should have beneficial knock-on effects for the Nav Editor - props to @gwwar for her work here.
• We could do with the ability to (multi) select non-consecutive blocks. This PR from @swissspidy looks promising but additional help much appreciated.

[spacedmonkey]

I created a number of issues related to menus.

• Improve handling of html markup in Navigation Label
• ✅ Add block inserter to navigation editor
• ✅ Add support for custom post types in navigation editor
• ✅ Add support for custom taxonomies in navigation editor
• ✅ Navigation editor should respect show_in_nav_menus

Adding support from custom post types / taxonomies should be a blocker for getting this out of experiment, as it would make the menu screen unusable for those with CPT / CT.

[talldan]

The #34224 issue is listed in both High and Normal priority lists.

#34232 was also in both, so I've removed it from high priority. I feel like we even said it was low priority in the hallway hangout, but can't remember for sure.

[getdave]

Thanks for creating these! 👍

I created a number of issues related to menus.

@spacedmonkey Have you added these to the relevant sections above? If not then we'll need to look at that. I'll check now.

Update: I marked ✅ next to all your items which I've added to the relevant sections. One is remaining as I'm genuinely not sure about it and would like to discuss and learn more from you.

Adding support from custom post types / taxonomies should be a blocker for getting this out of experiment, as it would make the menu screen unusable for those with CPT / CT.

Anything that makes the screen unusable feels like a blocker. Let's investigate this one further. Adding to High list.

[spacedmonkey]

I also work like to flag this issue #31551 . It is important that we maintain backwards compatibility and solve backwards compat for ACF, we likely cover lots of other use cases of users that have extended the current menu screens. i have posted my idea of compatibility #31551 (comment). I would love some feedback.

[talldan]

Update - 2021-09-15

• Work is still progressing on migrating the navigation editor fully over to the REST API. The REST API changes have been merged, and now the front end code is being updated.
• Lots of UI changes this week with the editor top bar being updated, the main block inserter added, and fixes to the block's styles
• Good discussion underway on how to provide backwards compatibility for custom fields on the existing Menus screen.
• Up next: We're looking into bulk adding links, and using theme.json to control aspects of the navigation block.

We're always looking for contributors to help work on the Nav Editor and block - it you're interested please head over to the #feature-navigation-block-editor Slack channel. Look forward to seeing you there.

[getdave]

Update - 2021-09-22

• Lots of working happening on High priority items. Thanks for everyone who is contributing so much work 🙌
• REST API interactions have been improved and more issues identified.
• A tonne of bugs got fixed 🐛
• Started looking at ways to add links in Bulk.
• Using Theme JSON to control the block in the editor has been ruled out 😞
• Another Hallway Hangout is on the cards - dates/times to be confirmed.

[getdave]

Update - 2021-09-29

• Discussion is ongoing on the best way to ensure interoperability and compatibility between Nav block and Nav Editor.
• Proposal to utilise a new classic Menu block in the Nav Editor is ongoing. Any feedback welcomed.
• Folks (particularly @spacedmonkey) have been working hard on backwards compatibility. Any more feedback on this Issue would be a great help.
• Lots of bug fixes continue to roll in for the Editor. Great work by everyone involved.

[getdave]

Update - 2021-10-06

• Discussion is still continuing on the best way to ensure interoperability and compatibility between Nav block and Nav Editor.
• Looks like there will be a Hallway Hangout on Wednesday 13th October (TBC). Agenda will be posted to Make Blog.
• @talldan posted a nice summary of current state of things in Slack. There's a lot of great energy in the team right now and we are looking to coalesce around a shared set of objectives.

[getdave]

Update - 2021-10-20

• The Nav Editor will not be included in WordPress 5.9 - this is because:
  • changes to the block are required for the editor to be a success (see below).
  • we need to allow sufficient time to test the editor before any major release and allow for community feedback.
• Following the Hallway Hangout a summary was posted. The outcome was:
  • in the short term, contributor efforts will switch to the Nav block in order to resolve some of the underlying architectural issues
  • specifically separating the navigation's presentation from its data in order to make navigations reusable. This serves both the Nav Editor project and the WordPress 5.9 release in general.
  • The Navigation Editor will ultimately focus on manipulating the data of a navigation which is why the above work is a prerequisite for the project's success.
  • Work on the Nav Editor will resume after WordPress 5.9. We will continue to focus on backwards compatibility whilst looking ahead to the world of blocks.
  • It's unlikely that we will pursue a new "Classic Menu" block. Rather focusing on the Navigation block (or its data).
• To this end @talldan has two important Nav block PRs which everyone is encouraged to test and provide feedback on.

[draganescu]

I will close this tracking issue for the time being. The work continues on the navigation block.