Gutenberg contributors have shifted their efforts to focus on the Navigation Block ahead of WordPress 5.9, leaving the Navigation Editor for a future release. Recent check-ins on the progress have further narrowed the scope from what Matias Ventura previously projected to include “both the navigation block and navigation screen projects.”
“The Nav Editor will not be included in WordPress 5.9 because changes to the block are required for the editor to be a success,” Automattic engineer and core contributor Dave Smith said. “We need to allow sufficient time to test the editor before any major release and allow for community feedback.”
During a recent Hallway Hangout meeting, contributors discussed some of the challenges they have encountered in working on the Navigation Editor. Smith said the outcome of that meeting was that “contributor efforts will switch to the Nav block in order to resolve some of the underlying architectural issues.” Contributors and participants in the meeting agreed that the Navigation Editor needs to be on hold until the Navigation Block has been shipped.
Smith summarized the scope update for block-based Navigation in WordPress 5.9 and the changes to the block that are necessary for the project to move forward:
- 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).
As part of the effort to separate the navigation’s presentation from its data, contributors are considering two important PR’s that explore different approaches:
Discussion on the the merits and detriments of both approaches will continue before contributors select one to embrace moving forward. Smith identified the following goals as being important factors for the architectural decision:
- Allow navigations to be used in different locations within the same template/site.
- Allow reuse of the same navigation data but with different presentational treatments.
- Retain ability to quickly build new navigations.
- Separate presentation and data in order to afford editing navigation data in isolation (e.g. Nav Editor project).
- Allow reuse of navigations across themes.
Although having a complete Navigation Editor would be ideal for launching alongside WordPress 5.9’s other full-site editing features, it makes sense that contributors are taking their time deliberating the architectural approach that will define menus in WordPress for the foreseeable future. Anyone with strong opinions on the future of Navigation in WordPress should test the PR’s and weigh in on the discussion.
Like this:
Like Loading…
