Cover Block: Fix dark mode detection for featured images in template context

[dpmehta]

What?

Fixes the Cover block incorrectly rendering with light mode (is-light class) when using "Use Featured Image" in a template context without an overlay.

Fixes #74706

Why?

When a Cover block is configured to use a featured image in a template (e.g., single post template), the isDark attribute is calculated at template save time. However, at that point, no actual featured image exists to analyze for color detection.

The editor's color detection defaults to white (#FFF) when no image is available, resulting in isDark: false being saved. This causes the is-light class to be added, making text black, even when the actual featured image on the frontend is dark.

In contrast, Cover blocks added directly to a post correctly analyze the featured image and set isDark appropriately.

How?

In the PHP render callback (index.php), when useFeaturedImage is true and no overlayColor is set, we remove the is-light class from the block wrapper.

This aligns with the default isDark: true assumption in block.json, ensuring text remains readable on dark featured images when no overlay is present.

When an overlay color is set, the overlay determines text contrast, so we preserve the saved class.

Testing Instructions

1. Create a new Single Posts template
2. Add a Cover block → Set to "Use Featured Image" → Remove the overlay (set opacity to 0 or clear the color)
3. Save the template
4. Create a new post → Set a dark featured image
5. View the post on the frontend

Expected: Text in the Cover block should be white (readable on dark background)

Before fix: Text was black (is-light class incorrectly applied)

Screenshots or screencast

Before

---

After

cover-block-fix.mp4

[github-actions]

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @dpmehta! 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.

[github-actions]

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Required label: Any label starting with [Type].
• Labels found: [Package] Block library, First-time Contributor.

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

[github-actions]

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Required label: Any label starting with [Type].
• Labels found: [Package] Block library, First-time Contributor.

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @codecomp.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Unlinked contributors: codecomp.

Co-authored-by: dpmehta <mehtadev@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.