The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.?Create a ticket in the bug tracker.
Since the last update, contributors have added many new features to the Navigation blockBlockBlock 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. and also the wider navigation management system within WordPress.
These improvements are designed to help users manage their navigation menus and provide a more consistent and reliable experience.
Let’s take a look at what’s changed…
Navigation List View
One aspect of the navigation block is that parts of it are often hidden – for example submenus aren’t always open. This can make managing the items within a navigation block in the editor canvas challenging.
In addition to the standard block tools, the list view allows all the usual ways of managing navigation items. You can:
Add and remove navigation items.
Reorder navigation items.
Create new submenus.
Adding this feature to the block also prepared the groundwork to allow contributors to unlock several exciting new features in WordPress 6.3.
Navigation in Site View
With WordPress 6.3, it is now possible to manage your navigation from outside of the context of a Navigation block and without needing to edit a template.
When in the Site Editor a new “Navigation” section is available within the Site View sidebarSidebarA sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. which lists all of your navigation menus and allows you to manage them without having to find the templates (and blocks) they are used within:
One benefit of this view is that when multiple blocks all share the samenavigation menuNavigation MenuA theme feature introduced with Version 3.0. WordPress includes an easy to use mechanism for giving various control options to get users to click from one place to another on a site., the user now has a single place to manage the menu items.
Focus Mode for Navigation
Surfacing navigation as a list within the Site View is excellent for simple use cases, but sometimes it’s useful to see the navigation within the editor canvas to better visualize the changes being made.
For this reason WordPress 6.3 sees the addition of “Focus Mode” for Navigation whereby the navigation menu is displayed within an editor canvas completely isolated from any surrounding site context.
You can access this new mode by clicking on the “Edit” button within the Navigation block’s toolbar, or by browsing to an individual navigation from the “Navigation” section of the Site View sidebar.
Focus mode provides full scope to modify the blocks that are inside the navigation block (the “menu items”), allowing you to add new items and even make use of the editable list view in the block’s sidebar:
It is important to note that as a given navigation menu may be used across multiple block’s on a site – each of which will have their own place within the overall design of your site – the ability to change the visual representation of the Navigation block itself has been intentionally disabled.
This allows you to focus soley on the contents of the navigation menu.
Another benefit of this feature is that it is now possible to access and edit the inner blocks of a navigation simply by switching the editor to “code view” mode:
Managing your navigation in isolation can be extremely useful, but sometimes it’s handy to see your navigation menu within the context of which it is being displayed. This is precisely what the next feature seeks to address.
Navigation in Patterns and Template Parts
Patterns and Template Parts often contain navigation block’s. The classic example of this is a “HeaderHeaderThe header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes.” template part containing a site logo block and a navigation block.
This gives you quick access to manage the navigation that is used in the canvas without needing to switch to editing the block directly within the canvas itself.
Previous versions of WordPress had the concept of a “fallback” Navigation which was utilized in scenarios where a Navigation block has no navigation menu associated with it.
Depending on whether the site had existing Navigation Menus, the mechanism would either fetch an existing navigation or create a newone from scratch.
However the implementation provided a suboptimal user experience, with a noticeable loading delay upon block modification caused by fetching/creating the (“fallback”) navigation menu to be associated with the block.
This has been achieved by moving the majority of the fallback logic to the WordPress REST APIREST APIThe REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/.. A new dedicated “Navigation Fallback” endpoint now immediately returns the most “suitable” fallback navigation menu for your site.
What does “suitable” mean? This is much the same as for WordPress 6.2, namely when called the endpoint…
Returns the most recently created existing Navigation Menu.
(if not available then…) Returns a Navigation Menu created from the most recently created Classic Menu (note: this is a one time import, and changes to the original Classic Menu are not synced to the block-based Navigation Menu).
(if not available then…) Creates and returns a new Navigation Menu, typically comprising a list of the current site’s Pages.
This heuristic may evolve in future releases to allow the fallback to be sensitive to the context in which it is being displayed. For now however, the improvement to the block’s user experience and reliability is a welcome improvement over previous versions.
Opting out of automatic fallback creation
If you’d like to opt out of automatic creation of Navigation fallbacks you can use the wp_navigation_should_create_fallback hook as follows:
On top of the improvements to perceived performance delivered by improving the fallback navigation system, WordPress 6.3 also provides an additional enhancementenhancementEnhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. to the performance of the navigation system.
This simple change makes it possible to access and manage your navigation, which is a key facet of most websites and makes for a greatly improved user experience.
Login/Logout
It is common for websites to provide a login and logout link for their users. In #49160 we added this block to the list of blocks that are allowed within the navigation block so that users can add this functionality to their navigation.
What do you think?
This concludes our brief overview of the key changes to the navigation system in WordPress.
As always we are open to your feedback. What do you think? Are these improvements impactful for you? What is missing and what you would like to see? Your thoughts are appreciated in the comments below.
Of course, whilst there has been much progress contributors recognise that there is still much to do.
Our focus for future releases will be updated on the relevant Tracking Issue and we encourage you all to take a look and let us know any feedback you might have on the proposals outlined there.
You can also join us on WP CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. (sign up required) in the #feature-website-navigation channel.
Props to @scruffian who co-authored this post and to @draganescu and @annezazu for review.
The blockBlockBlock 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.-based Navigation editor screen has been behind an “experimental” feature flag within the GutenbergGutenbergThe 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/pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party for some time. The purpose of the call was to outline the work required in order to remove the “experimental” status from the screen in order that the editor is active by default in the Gutenberg plugin.
The team working on the feature feel this is valuable in order to increase the visibility of the feature and therefore improve the quantity of feedback we receive.
Meeting Recording
If you’d like to watch the full recording of the session you can do so below:
Key points agreed
It was agreed that the prerequisite for removing “experimental” was: UIUIUser interface/UXUXUser experience feature parity with the existing Navigation screen (nav-menus.php) in CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress..
We also acknowledged that:
We wouldn’t commit to feature parity of developer focused APIs at this stage.
Removing “experimental” in the Gutenberg plugin, would not automatically make the feature ready for merging into Core (that won’t happen until WordPress 5.9 at the earliest).
What was discussed?
The format of the hangout was an open discussion comparing and contrasting the classic menu screen with the experimental block-based navigation screen.
To this end attendees were asked to test drive both screens and note down their findings prior to the call.
The meeting facilitators also prepared a list of items as discussion points which were worked through during the call.
Each item was demonstrated, discussed and then assigned a loose priority of High/Medium/Low based on how critical the group felt the issue was to achieving feature parity.
Outcomes
The key outcomes of the call were:
A clearer understanding of the current project roadmap and the next steps required.
Contributors working on the Nav Editor will now look to reorganise and reprioritse the tracking issue around the problems identified during the call.
All items will be added to the tracking issue (with the possible exception of bugs).
The High priority section of the tracking issue will be reformed and refocused around the goal of “removing the experimental status from the Navigation Editor”. Only tasks directly related to this goal will be considered for inclusion in the “High” priority section.
Tasks identified during the call that were marked as Medium or High till be added to the aforementioned High priority section of the tracking issue.
Contributors will focus on tackling High priority tasks in order to realise the goal of removing the “experimental” status.
All contributors are encouraged to become involved in prioritisation. Everyone is welcome and we’d very much value your feedback. If you feel a priority is wrong or missing then please let your fellow contributors know.
Thanks to everyone who attended the hangout and we look forward to moving the Navigation Editor forward together.
Now that the new menu system patchpatchA special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. is in and working, I’ve been able to start going through it for UIUIUser interface stuff. The are some things I think we should consider changing to fit into the WP UI, though based on timing I’m also okay with letting some of it slide until next release if needed. Here are the things on my mind, which hopefully we can touch on during today’s dev chat.
Icons. The edit/delete/view icons are inconsistent with the way we handle actions everywhere else in WordPress. We have two options here: we can have icons made that will match WP coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. icons, or we can get rid of the icons and change the UI a bit to match existing interaction models. If we go with icons, I’ll ask Ben to make us some that match better, which might be the better part of valor to get 3.0 out on time, rather than trying to make everything perfect. Release early and keep iterating, right?
AccessibilityAccessibilityAccessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility). The menus function as it stands now is completely inaccessible. There doesn’t seem to be a no-JavaScriptJavaScriptJavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. version, which we have to have. It will be clunky and ugly, like widgets, but we NEED to do this. Icons for actions rather than text is an accessibility no-no, which is another reason to move away from them eventually, but the bigger problem is that we need a no-JSJSJavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. version. I’m emailing the accessibility list to see if anyone there is willing to pitch in and help.
Little arrows on the left of each item. These should be removed. We use little arrows everywhere else to indicate an open/close functionality. If we need a symbol to indicate hierarchy we could use dashes like some other plugins do, or better and more attractive, just indent the bar itself? We also need to get rid of those little mini-arrows in the modules on the right when you click on View All.
Everywhere else in the adminadmin(and super admin), the right-left convention is opposite of how it is on this screen. For example, in Widgets, the available widgets are on the left and the completed sidebars are on the right. On categories and tags, you add on the left and see the updated list on the right. It would probably make sense to swap the menu and the menu controls so the controls are on the left and menus are on the right.
Buttons. The Save button should use the primary button class (blue). It should also be furthest to the right. Delete should not be a button, but a red link, and to the left.
Display. Like some other people, I’m wondering why each menu has to have its own screen, when it’s generally a pretty narrow column.
Default menu. When you first go to the menu screen, it says you don’t have any menus, to create one, but that’s both confusing and incorrect. There is a default menu in place using pages (or categories, in some themes). We should either a) (and preferably) Display the pre-existing menu as Main Menu or some such, or b) change the default text to explain that they currently use the default menu, and this screen is for customizing. It’s also highly unclear how someone should name a menu, or what the relationship is between menus and themes. If someone creates 20 menus but none are supported by the theme, what will happen? It should really pre-fill what menus you have available to you, just like it does with sidebars on the widgets screen.
The click to add icons perform the same action as the page/categoryCategoryThe 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. titles themselves. The icons impair accessibility. If we are to have a second addition mechanism, it should be a text link, not an icon.
The mechanism for adding URLURLA specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org and adding page/category is inconsistent. Pages and categories have a list from which you can add, while links are added to menu directly. It would be more consistent to create link rather than add link when it’s first entered, then have link appear in a list below, as the pages and categories do, so that links could be added to/removed from menus without just deleting them. This would also follow the principle we established in widgets that you shouldn’t lose settings when you deactivate something like that.
The metaboxes down the right all show the on-hover gray arrow in the right headerHeaderThe header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. corner, but the boxes don’t collapse. Either make the boxes collapsible or get rid of the hover arrows.
Instead of the edit icon, each menu item should have the hover arrow, which would open it to the edit view. Then we should use save/close/delete as in widgets, thus getting rid of the delete icon as well. This is the interaction model for this type of metacontent and should be followed.
I don’t really see the need for a View link (icon) from each menu item.
Whatever we do in terms of these changes, hooksHooksIn WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. need to be included so that Woo can get their own current look back if they choose, as that was part of the agreement.
This is the kind of thing that we need a styleguide for, which the UI group has recently started working on. 🙂
