Cover: Add automatic sticky header height detection

[JosVelasco]

What?

Implements automatic detection and adjustment for Cover blocks set to 100vh height when sticky headers are present on the page.

Why?

Closes #51015

When a Cover block is set to 100vh and there's a sticky header on the page, content at the bottom of the Cover block gets hidden behind the sticky header. This creates a poor user experience where important content is inaccessible.

How?

The solution automatically detects sticky Group blocks containing header template parts and subtracts their height from Cover blocks set to 100vh.

Detection Logic

The implementation searches for:

1. Group blocks with position: sticky (via inline style or .is-position-sticky class)
2. That contain a header template part:
   • Elements with data-area="header" attribute (explicit headers)
   • Semantic <header> elements with template part class
   • Any template part inside a sticky group (for broader compatibility)

Implementation Details

• JavaScript detection (sticky-header-utils.js): Calculates total sticky header height including margins
• CSS custom property: Sets --wp-sticky-header-height on document root
• CSS rule (style.scss): Applies calc(100vh - var(--wp-sticky-header-height)) to Cover blocks with inline min-height: 100vh
• Dynamic updates: Uses ResizeObserver and window resize listeners to update when header size changes
• Editor integration (edit/index.js): useEffect hook ensures detection runs in the editor
• Frontend script (index.php): Inline script runs on DOMContentLoaded for frontend

Technical Approach

• Uses CSS custom properties for clean separation between detection and styling
• Falls back gracefully when no sticky header is detected (0px)
• !important flag ensures inline styles are overridden
• Works in both Site Editor and Post Editor
• Fully responsive and updates automatically

Testing Instructions

Setup

1. Create a Group block and set it to position: sticky (Styles → Position → Sticky)
2. Add a Header template part inside the Group (or any content for testing)
3. Below the sticky group, add a Cover block
4. Set the Cover block's min-height to 100vh (Dimensions → Min height → 100 → vh)

Expected Behavior

• The Cover block should automatically adjust its height to account for the sticky header
• Content at the bottom of the Cover block should be fully visible (not hidden behind the header)
• When you resize the browser window, the Cover block should adjust accordingly
• Works on both frontend and in the editor

Test Scenarios

• Cover block (100vh) with sticky header above it
• Cover block (100vh) without any sticky header (should remain 100vh)
• Sticky Group without header template part (should not affect Cover)
• Multiple Cover blocks on same page
• Header height changes responsively
• Works in Site Editor
• Works in Post Editor
• Works on frontend

[github-actions]

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @JosVelasco! In case you missed it, we'd love to have you join us in our Slack community.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.

[JosVelasco]

PR Comment: Testing Notes

Testing Note for Reviewers

Important: WordPress Core vs Gutenberg Plugin

When testing this PR locally, please note that WordPress Core may load its built-in Cover block before the Gutenberg plugin version, which will prevent these changes from taking effect.

Symptoms

If you see this error when testing:

Fatal error: Cannot redeclare render_block_core_cover() 
(previously declared in /wp-includes/blocks/cover.php:18)

This means WordPress Core is loading first and conflicting with the Gutenberg plugin version.

How to Test This PR

Option 1: Disable Core Cover Block (Recommended)

Temporarily prevent WordPress Core from registering the Cover block by adding this to your theme's functions.php:

add_action( 'init', function() {
    if ( class_exists( 'WP_Block_Type_Registry' ) ) {
        $registry = WP_Block_Type_Registry::get_instance();
        if ( $registry->is_registered( 'core/cover' ) ) {
            $registry->unregister( 'core/cover' );
        }
    }
}, 5 ); // Priority 5 to run before Gutenberg registers at priority 10

This ensures the Gutenberg plugin version loads instead.

Option 2: Test with Gutenberg as Plugin Only

Use a WordPress installation where Gutenberg is loaded purely as a plugin, not embedded in Core. This is typically:

• WordPress versions before the block editor was integrated into Core
• Custom WordPress builds with blocks disabled

Option 3: Modify Core File for Testing

For quick local testing, you can apply the same changes to WordPress Core's version at:

/wp-includes/blocks/cover.php

However, this is only for testing purposes - the actual fix should go through this PR to eventually be merged into Core.

Why This Happens

WordPress Core includes a version of the Cover block at /wp-includes/blocks/cover.php. When both Core and the Gutenberg plugin try to register the same block, PHP throws a fatal error because the render_block_core_cover() function is being declared twice.

This is a known challenge when developing Gutenberg features that need to override Core blocks.

Verification After Setup

Once you've disabled the Core version, verify the fix is working by running this in the browser console:

const scripts = Array.from(document.querySelectorAll('script'));
const hasCoverScript = scripts.some(s => s.textContent.includes('getStickyHeaderHeight'));
const cssVar = getComputedStyle(document.documentElement).getPropertyValue('--wp-sticky-header-height');

console.log('Gutenberg Cover script loaded:', hasCoverScript ? '✅' : '❌');
console.log('CSS variable value:', cssVar || '(not set)');

if (hasCoverScript && parseFloat(cssVar) > 0) {
    console.log('✅ Fix is working correctly!');
}

You should see:

• Gutenberg Cover script loaded: ✅
• CSS variable value: XXpx (the height of your sticky header)
• ✅ Fix is working correctly!

---

Long-term Solution

Once this PR is merged into Gutenberg and eventually synced to WordPress Core, this conflict will resolve naturally as both will have the same implementation.

Let me know if you encounter any issues testing this PR!