The WordPress Full Site Editor changed how themes handle navigation in significant ways. The traditional functions.php registration of menu locations, the wp_nav_menu() function, the familiar Appearance → Menus interface — all of these still exist, but FSE themes often bypass them entirely in favor of the Navigation block.
For users who want to add a third-party mega menu plugin to an FSE theme, this creates some friction worth understanding.
The Navigation block and its limitations
FSE themes typically use the core Navigation block to manage menus. This block is powerful for simple navigation, but it doesn’t support the kind of structured mega menu output that plugins like Ruby produce. You can’t add a third-party plugin’s output to a Navigation block — it’s designed for the block editor’s own menu structure.
The Custom HTML block approach
The practical solution for FSE themes is to add the mega menu plugin via a Custom HTML block in the Site Editor, typically in the header template. This bypasses the Navigation block entirely and lets the plugin render its own output.
One important detail: use a Custom HTML block, not a Shortcode block. The Shortcode block passes content through WordPress’s wpautop filter, which wraps block-level elements in <p> tags — this corrupts the menu’s HTML structure. The Custom HTML block doesn’t do this.
Z-index and stacking contexts
FSE themes often create stacking contexts in ways that traditional themes don’t. The wp-site-blocks wrapper, which FSE themes use for layout, can establish a stacking context that confines dropdown z-index values. This means your dropdowns might render at a high z-index but still appear below other elements.
Ruby handles this with :has(#ruby-mega-menu) selectors that adjust the stacking context of ancestor elements. This is a CSS-only fix that doesn’t require modifying the theme.
Global style bleed-in
FSE themes define their typographic and color styles globally, and these can bleed into plugin-rendered elements. Ruby’s reset layer handles most of this, but it’s worth checking heading styles, link colors, and font families inside the menu panel after setup.
Dynamic CSS loading
Plugins that generate dynamic CSS — Ruby does this for custom colors, widths, and typography set in the admin — need to ensure that CSS loads once and only once. In FSE themes, where the same page might trigger multiple render passes, double-loading is a real risk. Ruby loads its dynamic CSS exclusively via the wp_head hook to prevent this.
FSE compatibility is solvable. The patterns are established, and Ruby handles them explicitly. But it’s worth knowing the landscape before you start, so you’re not surprised by behavior that looks like a bug but is actually expected FSE behavior.