Tag Archives: navigation

David Smith 2:34 pm on March 4, 2026
Tags: , , navigation   

Customisable Navigation Overlays in WordPress 7.0

WordPress 7.0 introduces Customisable Navigation Overlays, giving site owners full control over their mobile navigation menus using the 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. editor.

Previously, when a visitor tapped a hamburger menu icon on a mobile device, WordPress displayed a fixed default overlay with no support for customisation. The design, layout, and content were locked.

Customisable Navigation Overlays remove this restriction entirely — any overlay can now be built from blocks and patterns in the Site Editor. This includes a dedicated Navigation Overlay Close block for placing and styling a close button anywhere within the overlay.

How overlays work

Navigation overlays are implemented as template parts using a new navigation-overlay template part area, managed principally through the Navigation block’s overlay controls in the Site Editor. Because they are template parts, they can also be found and edited via the Patterns section in the Site Editor sidebarSidebar A 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.. Each overlay is assigned to a Navigation block — while the same overlay can be referenced by more than one, a one-to-one relationship is the most common pattern.

What goes inside an overlay is entirely up to the author. As a standard block canvas, it can contain any block — navigation, social icons, a search field, a site logo, calls to action…or any combination! A Navigation block is the typical inclusion but is not a requirement. Because overlays only function correctly when rendered by a Navigation block, overlay template parts are intentionally excluded from the general block inserter — this prevents them from being inserted accidentally into other parts of a template.

The feature is opt-in: by default, the Navigation block continues to use the standard overlay behaviour from previous versions of WordPress. A custom overlay can be activated in three ways:

  • Creating a new overlay — via the Overlays section in the Navigation block’s sidebar controls in the Site Editor
  • Selecting an existing overlay — from the same controls, choosing from any overlays already created or bundled with the active theme
  • Theme pre-assignment — a theme can reference a bundled overlay directly in the Navigation block markup (covered in the developer section below)

For theme developers: bundling overlays with your theme

Themes can ship pre-built navigation overlays so they are available as soon as the theme is activated. The recommended approach is to provide both a default overlay template part and a set of overlay patterns.

Template parts vs patterns

Understanding the distinction helps decide how to structure an overlay offering:

  • A template part is the overlay itself — the component that gets rendered when a Navigation block uses an overlay. Shipping a template part means a ready-to-use overlay is available from the moment the theme is activated.
  • Patterns are design options that appear in the Design tab when editing a navigation overlay in the Site Editor. Selecting a pattern replaces the current overlay content with the pattern’s block markup, letting users switch between distinct designs.

A patterns-only approach is also valid — useful when a theme wants to offer design options without pre-applying an overlay automatically. In this case, users create a new overlay via the Navigation block’s controls and pick from the theme’s patterns as a starting point.

Updating your Theme

1. Register the template part in theme.json

Registering the template part in theme.json is required. Without it, the template part is assigned the uncategorized area and will not be recognised by the Navigation block as an overlay.

Add an entry to the templateParts array, setting area to navigation-overlay:

{
    "templateParts": [
        {
            "area": "navigation-overlay",
            "name": "my-custom-overlay",
            "title": "My Custom Overlay"
        }
    ]
}

2. Create the template part file

Create the corresponding HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. file in the theme’s parts/ directory. The filename should match the name value from theme.json.

It is strongly recommended to include the Navigation Overlay Close block within the overlay. If it is omitted, WordPress will automatically insert a fallback close button on the frontend for accessibilityAccessibility Accessibility (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) and usability reasons — but that button may not match the overlay’s design or be positioned as expected. Including it explicitly gives full control over its appearance and placement.

<!-- parts/my-custom-overlay.html -->
<!-- wp:group {"layout":{"type":"flex","orientation":"vertical"}} -->
<div class="wp-block-group">
    <!-- wp:navigation-overlay-close /-->
    <!-- wp:navigation {"layout":{"type":"flex","orientation":"vertical"}} /-->
</div>
<!-- /wp:group -->

3. Register overlay patterns

Overlay patterns are registered using register_block_pattern(). Setting blockTypes to core/template-part/navigation-overlay scopes the pattern so it only appears when editing a navigation overlay template part — not in the general inserter.

register_block_pattern(
    'my-theme/navigation-overlay-default',
    array(
        'title'      => __( 'Default Overlay', 'my-theme' ),
        'categories' => array( 'navigation' ),
        'blockTypes' => array( 'core/template-part/navigation-overlay' ),
        'content'    => '<!-- wp:group {"layout":{"type":"flex","orientation":"vertical"}} -->
<div class="wp-block-group">
    <!-- wp:navigation-overlay-close /-->
    <!-- wp:navigation {"layout":{"type":"flex","orientation":"vertical"}} /-->
</div>
<!-- /wp:group -->',
    )
);

4. Pre-configuring the Navigation block (optional)

A theme can optionally pre-configure a Navigation block to reference a specific overlay by setting the overlay attribute in the block markup. The value should be the template part slug only — without a theme prefix:

<!-- wp:navigation {"overlay":"my-custom-overlay"} /-->

Using the slug only — without a theme prefix — is important for future compatibility: WordPress plans to allow template parts to persist across theme switches, and a theme-prefixed identifier would break that. This follows the same convention as header and footer template parts.

The overlay attribute is entirely optional — users can select or change the overlay at any time using the Navigation block’s sidebar controls.

Known limitations

Template parts and theme switching

Navigation overlay template parts are currently tied to the active theme. Custom overlays will not be preserved if the active theme is switched. This is a known limitation tracked in gutenberg#72452.

Overlays are full-screen only

In this initial release, navigation overlays are always rendered full-screen. Non-full-screen overlay styles (such as a sidebar drawer) are not yet supported. This requires implementing overlays as a true <dialog> element — including support for clicking outside to close — which is planned for a future release.

Not a generic popup or dialog

Navigation Overlays are intentionally scoped to the Navigation block and are not designed as a general-purpose popup or dialog implementation. For broader use cases — such as modal dialogs triggered by arbitrary content — a dedicated Dialog block is in development and tracked in gutenberg#61297.

Questions and feedback

Until now, the mobile navigation overlay has been one of the few remaining areas of a block theme that couldn’t be designed in the Site Editor. Navigation Overlays change that. An overlay can contain anything blocks can express — a simple menu with a styled close button, a full-screen layout with the site logo and a call to action, or a content-rich experience that turns the mobile menu into a destination in its own right.

There is a lot of creative space here, and seeing what the community builds with it will be exciting.

Questions are welcome in the comments below.

Further reading

Props @onemaggie for implementation contributions and technical review, @mikachan, @jeryj @scruffian for proofreading, and @mmcalister, whose Ollie Menu Designer pluginPlugin A 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. helped validate community demand for this functionality.

#7-0, #dev-notes, #navigation

David Smith 2:21 pm on August 23, 2023
Tags: , , , navigation,   

What’s new for Navigation in WordPress 6.2 and 6.3

This post was co-authored by @scruffian.

Since the last update, contributors have added many new features to the Navigation 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. 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. 

For this reason, WordPress 6.2 added an editable “List View” component to the navigation block inspector controls which lays out the navigation structure with every item visible:

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 sidebarSidebar A 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 you click through to a Navigation you can:

  • Rename, duplicate and delete navigation.
  • Reorder items within a navigation.

Known limitation: currently you cannot add new items, but contributors are considering avenues to enable this for a future release.

One benefit of this view is that when multiple blocks all share the same navigation menuNavigation Menu A 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 “HeaderHeader The 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.

In WordPress 6.3, when editing a template part or a pattern that contains a navigation block, you will see any associated navigation menu displayed in the sidebar in an editable list view.

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. 

Moreover, by displaying the name of the navigation in the sidebar, it is immediately apparent which navigation menu is being used by the block. In the future it may be possible to complement this in a reciprocal way when viewing a single Navigation Menu by listing the templates where the navigation is used.

Automatic creation of Navigation fallbacks

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 new one 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.

With WordPress 6.3 however, this experience has been greatly improved with each Navigation block now being automatically assigned a navigation menu upon insertion. This means that once a block is ready, edits will not trigger further “loading” delays as changes are simply synchronized to the navigation menu already associated with the block.

Technical Implementation

This has been achieved by moving the majority of the fallback logic to the WordPress REST APIREST API The 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:

add_filter( 'wp_navigation_should_create_fallback', '__return_false' );

See the original PR for full details.

Other improvements

Performance

On top of the improvements to perceived performance delivered by improving the fallback navigation system, WordPress 6.3 also provides an additional enhancementenhancement Enhancements 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.

In #48683 contributors added the navigation endpoints to the list of endpoints that are preloaded in the editor. This means that when the editor loads the list of navigation menus will already be available to display and use within the block and/or Site View sidebar. 

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.

Bugs – we appreciate it if any bugs are reported on Github.

What’s next?

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 CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. SlackSlack Slack 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.

#6-3, #dev-notes, #dev-notes6-3, #navigation, #navigation-block

David Smith 10:01 am on August 25, 2021
Tags: , , navigation, ,   

Hallway Hangout Summary: “compare and contrast” the Navigation screens

This post summarises the Navigation screen Hallway Hangout held on 2021-08-24 09:00 UTC in Zoom facilitated by @get_dave, @talldanwp and @javier.

The 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.-based Navigation editor screen has been behind an “experimental” feature flag within 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/ pluginPlugin A 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: UIUI User interface/UXUX User experience feature parity with the existing Navigation screen (nav-menus.php) in CoreCore Core 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:

Next Steps

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.

#feature-navigation-block-editor, #hallwayhangout, #navigation, #summary, #video

Jen 5:29 pm on February 25, 2010
Tags: , interaction models, , navigation, ,   

Menus UX Manifesto

A Menus Manifesto?

Now that the new menu system patchpatch A 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 UIUI User 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 coreCore Core 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?
  • AccessibilityAccessibility Accessibility (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-JavaScriptJavaScript JavaScript 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-JSJS JavaScript, 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/categoryCategory The '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 URLURL A 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 headerHeader The 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, hooksHooks In 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. 🙂

#accessibility, #interaction-models, #menus, #navigation, #ui, #ux