WordPress 7.0 finally addresses a frustration I’ve dealt with on almost every high-end design project: the hardcoded mobile menu. For years, once that hamburger icon was tapped, we were stuck with a rigid, default overlay. If a client wanted a search bar, social icons, or a specific CTA inside that mobile drawer, it usually meant a messy CSS hack or a custom JS modal that fought against the Navigation block’s core logic.
The introduction of Customisable Navigation Overlays changes that dynamic. Instead of a locked design, the mobile overlay is now a standard block canvas. You can build it using patterns, template parts, and any block in the library. This isn’t just a “nice to have” update; it’s a fundamental refactor of how mobile navigation is handled in the Site Editor.
Architecture: Template Parts as Overlays
Under the hood, Customisable Navigation Overlays are implemented as template parts within a new navigation-overlay area. This is a clean architectural move. Because they are template parts, they are portable and manageable via the “Patterns” section in the Site Editor. Typically, you’ll have a one-to-one relationship between a Navigation block and its overlay, though you can reuse them across different menus if needed.
One specific “gotcha” to watch for: these template parts are intentionally hidden from the general block inserter. You won’t accidentally drop a navigation overlay into your footer. They only function when rendered by a Navigation block. Furthermore, you should check out the WordPress 7.0 roadmap to see how this fits into the broader site editing vision.
Developing for Customisable Navigation Overlays
If you are a theme developer, you shouldn’t wait for users to build these from scratch. You need to bundle them. The workflow involves three specific steps: registration in theme.json, creating the HTML part, and optionally scoping design patterns.
1. Registration in theme.json
Without registering the area, your template part will be tagged as uncategorized and the Navigation block won’t recognize it. Here is the correct syntax for your theme.json:
{
"templateParts": [
{
"area": "navigation-overlay",
"name": "bbioon-mobile-menu",
"title": "Mobile Menu Overlay"
}
]
}2. The Template Part Markup
In your theme’s parts/bbioon-mobile-menu.html, you define the layout. I strongly recommend including the core/navigation-overlay-close block explicitly. If you omit it, WordPress will inject a fallback button for accessibility, but it usually looks like an afterthought and might break your layout.
<!-- 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 -->The Gotchas: Limitations and Reality Checks
While Customisable Navigation Overlays are a massive leap forward, they aren’t a magic bullet for every popup need. Specifically, in this initial 7.0 release, overlays are full-screen only. If you’re looking for a “slide-in sidebar” or a partial drawer, you’re still going to need custom CSS or a third-party library. This is because the core implementation hasn’t fully migrated to the <dialog> element yet, which is required for non-modal behaviors.
Additionally, remember that these overlays are tied to the active theme. If your client switches themes, the custom overlay layout won’t follow them—it’s not a plugin-level feature. This is documented in the official dev notes.
Look, if this Customisable Navigation Overlays stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
Takeaway for Site Owners
Consequently, the mobile experience on WordPress is finally catching up to modern design standards. You no longer need to hire a developer for a “quick fix” just to add a phone number or a search bar to your mobile menu. As long as your theme supports it, you can design that mobile destination directly in the Site Editor. It’s about time we stopped treating the mobile menu as a second-class citizen.
