WordPress 7.0 adds Customizable Navigation Overlays to the editor, and I have wanted this since the early days of Full Site Editing. If you have ever tried to make a client’s mobile menu look like something other than a plain list, you know the problem. The overlay was hardcoded, so adding a logo or a “Book Now” button meant a pile of CSS overrides.
The call for testing now open on Make WordPress covers the replacement. Instead of one fixed overlay for every site, the overlay becomes a template part you edit like any other part of the theme.
What the overlay change fixes
Until this release, styling the mobile hamburger menu was a hack. You fought the default rules with brittle selectors, and keeping one brand look across desktop and mobile ate hours that should have gone somewhere else.
The usual workaround was CSS injected into the menu container to show or hide things inside it:
/* The old, hacky way to add a logo to the mobile menu */
.wp-block-navigation__responsive-container.is-menu-open::before {
content: "";
display: block;
background: url('logo.png');
height: 50px;
margin-bottom: 20px;
}Customizable Navigation Overlays move that logic into the editor. Patterns and blocks work inside the overlay, so a Social Icons block, a Search block or a call-to-action button goes in with no custom CSS at all.
Overlays are template parts
Each overlay is saved as a template part, which is what makes it reusable. A shop page can get one mobile menu and the blog another, both managed in the Site Editor. Themes can also ship overlay patterns, so users start from something instead of an empty container.
I wrote earlier about handling WordPress core update regressions, and this is exactly the kind of feature worth testing early. Where the markup ends up in the DOM is still being argued over.
Where the markup should live
The open question in testing is where the overlay markup sits in the HTML. Four options are on the table: inside the <nav> element, as a sibling of it, or pinned to the very top or the very bottom of the page.
I lean toward keeping it near the trigger, because focus management is simpler that way. Pushing it to the end of the document does buy you something, though: fewer z-index fights with sticky headers. The SEO side is what I keep coming back to, since crawlers should not be reading the same navigation links twice.
That discussion is happening in the Gutenberg tracking issue on GitHub. If you can test how screen readers handle the focus trap inside these overlays, do it before the WordPress 7.0 feature freeze on February 9, 2026.
If the overlay work is eating your dev hours, I can take it off your plate. I have been building on WordPress since the 4.x days.
What this means for your ship dates
Don’t wait for the release to find out what this does to your custom themes. Open the WordPress Playground instance and run Scenario 2, building an overlay from scratch. If a complicated block stack breaks the mobile layout, report it while there is still time to fix it. An afternoon of testing now beats debugging after 7.0 ships.
