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.
In WordPress 6.1 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. will have a new fallback behavior.
What is the fallback behavior?
When a theme uses a navigation block in a template part, it’s to control where the navigation should visually be located, for the theme’s UIUIUser interface to be consistent, usable, and visually attractive. However, themes developers don’t know beforehand what menus the site has, how many pages, what they’re called and so on.
The fallback behavior is the small heuristics in the navigation block which tries to determine what the block should display by default, when a user activates a theme.
What is the new fall back behavior?
Starting with WordPress 6.1, theme developers and authors can lean on the following fallback behavior of the block:
If the navigation block has inner blocks, it will honor them and display them. If the navigation block is empty, however, then it will initialize the fallback behavior.
The fallback behavior (in both the editor and the front of the site) is:
If there are no block menus or classic menus, the block will display a list of available pages using the Page List block.
If there are multiple block menus, the navigation block will display the most recently created block menu.
The key changes can be summarized as follows:
Improved consistency.
Page List as default fallback.
Selecting the most recent block menu.
Consistency: previously the fallback behavior was inconsistent between the fronted of the site and the editor. If a theme used an empty navigation block it would display a list of pages on the front, and an empty block in the editor. Now the behavior is consistent between both; the editor mirrors what visitors see on the frontend.
Defaulting to page list: previously, themes which wanted to default to a page list in the editor usually included a page list inner block within the Navigation block. With this update, this is no longer necessary. The navigation block, if empty, will automatically have consistent front and editor behavior, defaulting to a page list.
Selecting the most recent block menu: This part of the fallback behavior is new. In the event a site has multiple block menus, an empty navigation block will display the most recent one.
Theme developers should keep in mind.
Display only
The fallback behavior only affects what the empty navigation block will display. Unless the user edits the navigation block’s default fallback, adding a link, changing a label, converting a page list block to a list of links or selecting another menu, the markup of the template part is not changed.
Default content is still honored.
There is no change to how navigation blocks with inner blocks from theme markup behave. Themes still include inner blocks in the markup in the event they want to showcase a specific situation, for instance a small three links menu, pointing to #, with some restriction on length of link labels – this will continue to work, just like before, rendering the uncontrolled inner blocks both on the front and in the editor.
Props: @get_dave for editing and technical review, @bph for review
WordPress 5.9 sees the introduction of a Navigation block which allows users to create, manage, and reuse menus built with various blocks from page links to site logos and more.
For full information on using 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. please see the Navigation block support page.
This guide will dive deeper into some of the more technical aspects of the block’s functionality.
Reusing Navigation Menus and separation of concerns
A key consideration when creating a block based navigation system has been to decouple the presentation of the Navigation block from its data (i.e. the menu items themselves).
The primary aim of this effort has been to allow for the easy reuse of menus across different Themes, whilst allowing Theme authors to apply different stylistic treatments to their navigation areas.
Changes made to the menu items within the Navigation block are automatically synchronised to an underlying Navigation Post.
In contrast, all presentational attributes remain local to the block instance itself and are not persisted to the Navigation Post.
By using a centralised data source, this “controlled” Navigation block affords reuse of Menus within the site and/or across Themes whilst still allowing for menus to be styled differently as required.
Reusing an existing Menu
To reuse an existing Menu the user may select a menu from the dropdown that appears when clicking on Select menu in the block interface.
Once selected the items from that menu will be added to the current Navigation block.
An association is also made between the block and the underlying data source via the ref attribute which references the ID of the Navigation Post.
As a result of the above mechanic, Theme developers can add Navigation blocks to locations within their Theme and style them to suit the visual design.
When a user activates the Theme they will then be presented with an option to choose from any existing Navigation Menus that they would like to use in those areas.
This affords simple reuse of menus across Themes.
Reusing and converting Classic Menus to block based Menus
In light of the advent of block-based Menus (and in line with similar previous nomenclature changes), we now refer to such menus as “Classic Menus”.
Thankfully, transitioning to creating a menu using the block editor doesn’t mean recreating existing Classic Menus from scratch.
Instead the Navigation block affords the ability to copy these menus and transform them into block based equivalents from within the block interface.
To reuse an existing Classic Menu, the user should first insert a new Navigation block. By choosing the Select menu option from the block placeholder they will reveal a dropdown displaying both existing block based and Classic menus.
Selecting a Classic menu will copy the Menu’s data, convert it to a block based form and then insert that menu data into the Navigation block.
Note that the original Classic Menu is not modified – there is no link between the original data and the new block based representation. Therefore should the user wish to switch back to a classic Theme, their original Classic Menu data will be preserved.
The need for 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 developers to hook into the conversion process has been recognised and an API is being worked on for a future WordPress release.
User Permissions
In Classic Menus, only users with the edit_theme_options capability (by default only users with the Admin role) could access the Appearance Menus screen to edit menus.
This is currently achieved by displaying a warning notice to the user within the editor interface if they have insufficient permissions to perform the desired (inter)action.
Note that currently it is still possible for the user to interact with the Navigation block itself. However, any changes to the underlying Navigation 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. data will not be persisted.
In future versions of the block, features may be added to make the block interface fully read only based on user permissions.
Backwards compatibility with 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/Plugin
Users of the Gutenberg Plugin may be aware that the Navigation block has existed for some time within the Plugin in a “BetaBetaA pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process.” form.
For early adopters who have been making use of previous iterations of the block there are two key considerations.
Handling legacy “uncontrolled” blocks
Users should note that previous implementations of the Navigation block saved the “items” to the block itself. This can be described as an “uncontrolled” version of the block, whereby the menu item data is local to the block (i.e. inner blocks) and thus persisted directly to the Post in which it is contained.
You must be logged in to post a comment.