WordPress 7.0 fixes something that has annoyed me on nearly every design-heavy build: the hardcoded mobile menu. Tap the hamburger and you got the default overlay, take it or leave it. A client who wanted a search field, social icons or a specific call to action inside that drawer meant either a CSS hack or a custom JS modal that spent its life fighting the Navigation block’s own logic.
Customisable Navigation Overlays change that. The mobile overlay is a normal block canvas now, so you build it out of patterns, template parts and anything else in the block library. That is a genuine refactor of how mobile navigation works in the Site Editor, not a coat of paint on the old drawer.
Template parts as overlays
Under the hood, each overlay is a template part sitting in a new navigation-overlay area. That is a sensible choice, since template parts are portable and you manage them from the Patterns section of the Site Editor. Most sites will end up with one overlay per Navigation block, though nothing stops you reusing one across several menus.
One thing to watch: these template parts are deliberately hidden from the general block inserter, so you cannot drop a navigation overlay into your footer by accident. They only render when a Navigation block calls them. The WordPress 7.0 roadmap has more on where this sits in the wider site editing plan.
Building overlays into a theme
If you build themes, bundle these rather than leaving users to assemble one from nothing. Three steps: register the area in theme.json, write the HTML part, then scope design patterns to it if you want to.
1. Registration in theme.json
Skip the area registration and your template part gets tagged uncategorized, which means the Navigation block will not recognise it. The syntax for theme.json:
{
"templateParts": [
{
"area": "navigation-overlay",
"name": "bbioon-mobile-menu",
"title": "Mobile Menu Overlay"
}
]
}2. The template part markup
The layout itself lives in your theme’s parts/bbioon-mobile-menu.html. Include the core/navigation-overlay-close block explicitly. Leave it out and WordPress injects a fallback close button for accessibility, which works, but it tends to look bolted on and it can throw your layout off.
<!-- wp:group {"layout":{"type":"flex","orientation":"vertical","justifyContent":"center"}} -->
<div class="wp-block-group">
<!-- wp:navigation-overlay-close {"style":{"spacing":{"margin":{"bottom":"2rem"}}}} /-->
<!-- wp:site-logo /-->
<!-- wp:navigation {"layout":{"type":"flex","orientation":"vertical"}} /-->
<!-- wp:social-links /-->
</div>
<!-- /wp:group -->Where it falls short today
Customisable Navigation Overlays are a big step, and they still do not cover every popup you might want. In this first 7.0 release the overlays are full screen only. A slide-in sidebar or a partial drawer needs custom CSS or a third-party library, because core has not fully moved to the <dialog> element yet, and that is what non-modal behaviour depends on.
The overlays also belong to the active theme. Switch themes and the custom overlay layout stays behind, because this is a theme-level feature rather than a plugin-level one. The official dev notes spell that out.
If navigation overlay work is eating your dev hours, hand it over. I have been doing WordPress since the 4.x days.
What this means for site owners
Mobile navigation on WordPress is catching up with how sites are designed everywhere else. Adding a phone number or a search field to the mobile menu is no longer a job you have to pay a developer for. As long as your theme supports the feature, you lay that screen out in the Site Editor like any other part of the site. For something most visitors actually use, that is overdue.
