Repository navigation
Navigation inside a core/pattern in an overlay template part escapes nested-overlay suppression #82286
Description
Activity
Two separate consequences, in case they want splitting:
- Nested overlay. The inner Navigation keeps
overlayMenu: "always", so it renders a
second responsive container and toggle inside the open overlay. - Nested landmark. Without
_isWithinOverlayTemplatePart, the renderer's
$tag_name = $is_within_overlay ? 'div' : 'nav';picksnav, producing a<nav>
inside a<nav>.
The narrow fix is presumably to expand patterns before the walk, or to apply the same
rendered-HTML strategy the close button already uses. Which one is right depends on whether
the attributes need to be rewritten before render, which they currently do.- Nested overlay. The inner Navigation keeps
Confirmed, this reproduces. Traced it down and also verified it with a quick PHPUnit test against wp-env.
The core issue is that
disable_overlay_menu_for_nested_navigation_blocks()inindex.phpwalks the parsed block tree of the overlay template part and rewrites anycore/navigationit finds (setsoverlayMenutoneverand marks it_isWithinOverlayTemplatePart). Butcore/patternblocks are still leaf nodes at that point — the pattern hasn't been expanded yet. It only gets expanded later, in a totally separate render pass:render_block_core_pattern()just runsdo_blocks()on the raw pattern content, completely outside the tree the walk already touched. So any nav inside a pattern never gets rewritten and renders with its original attrs — hence the nested<nav>and the second overlay container.To reproduce:
- Register a pattern whose content is a
core/navigationblock withoverlayMenu: "always"(a plain Navigation block with a link inside is enough). - Create a Navigation Overlay template part containing a
core/navigation-overlay-closeblock followed by acore/patternreference to that pattern. - Assign that template part as the
overlayon an outer Navigation block withoverlayMenu: "always", and render it. - For comparison, do the same thing again but paste the inner nav directly into the template part instead of going through the pattern.
I did this with a temporary test added to
class-wp-navigation-block-renderer-test.php(basically copied the existing shortcode-in-overlay test), building both template parts and diffing the rendered output:Direct case: 1
<nav>, no duplicated responsive-container.
Pattern case: 2<nav>elements and the responsive-container shows up twice — same numbers as in the issue writeup.(Removed the test afterward, it was just to confirm — tree's clean.)
Agree with the direction in the description: the close-button check already had to solve this exact problem (patterns not existing yet in the parsed tree) by checking the rendered HTML instead of the parsed blocks. Seems like the fix here should do the same thing — process the rendered overlay output after patterns are expanded, rather than trying to catch it in the pre-render walk.
Reacted by Jiwoon-Kim- Register a pattern whose content is a
Description
When a Navigation Overlay template part contains a
core/patternblock, and that patterncontains a
core/navigationblock, the inner Navigation is not suppressed. It renders itsown responsive overlay inside the outer overlay, and it renders as a
<nav>landmarknested inside the outer
<nav>.Both outcomes are things the renderer explicitly tries to prevent.
WP_Navigation_Block_Renderer::disable_overlay_menu_for_nested_navigation_blocks()walksthe parsed block tree of the overlay template part and rewrites every
core/navigationit finds:
core/patternis a self-closing node in that tree — its contents do not exist until rendertime — so a Navigation inside one is invisible to this walk.
The same file already knows about this timing difference elsewhere. Close-button detection
was moved to the rendered HTML precisely so it would keep working with patterns
(#76567 / #76585):
The nested-Navigation suppression did not get the same treatment.
Step-by-step reproduction instructions
core/pattern) whose content is a Navigationblock with Overlay Menu set to Always.
Reduced to the two code paths, on WordPress 7.1 with no plugins active:
Screenshots, screen recording, code snippet
Counting what the walk suppressed, and what the result renders:
suppressed—core/navigationblocks the walk found and rewroterendered <nav>—<nav>elements in the output, which is<div>when_isWithinOverlayTemplatePartis setoverlay container survives— presence ofwp-block-navigation__responsive-containerEnvironment info
disable_overlay_menu_for_nested_navigation_blocks()is unchanged there
Please confirm that you have searched existing issues in the repo.
Please confirm that you have tested with all plugins deactivated except Gutenberg.
Please confirm which theme type you used for testing.