Block Visibility: Keep hide-everywhere working after a block opts out of visibility support

[t-hamano]

What?

Closes #78701

Honor metadata.blockVisibility: false on the front end even after a block opts out of visibility block support, so HTML and Shortcode blocks saved while their support was enabled stay hidden.

Why?

Visibility support was disabled for the Shortcode block and the HTML block in #76138. This caused an unintended display of content on the front end.

How?

When metadata.visibility is false, block rendering is always prevented on the frontend.

As another issue, custom HTML blocks and shortcode blocks with metadata.visibility set to false lack a UI in the editor to make them visible again. Users must delete these blocks once. It might be possible to adjust the visibility UI display logic in the editor, but this seems a bit complex, so this PR focuses solely on frontend fixes.

Testing Instructions

Input the following code using the code editor:

<!-- wp:html {"metadata":{"blockVisibility":false}} -->
This HTML should not be displayed on the frontend.
<!-- /wp:html -->

<!-- wp:shortcode {"metadata":{"blockVisibility":false}} -->
[shortcode]
<!-- /wp:shortcode -->

The content should not be displayed on the front end.

Use of AI Tools

Drafted with Claude Code (Opus 4.7). All output reviewed and validated by the author.

[t-hamano]

I'm not yet convinced if this approach is ideal. If we are to move forward with this PR, I would like to submit a core PR.

[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: @krysek76.

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: krysek76.

Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: ramonjd <ramonopoly@git.wordpress.org>
Co-authored-by: talldan <talldanwp@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>

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

[github-actions]

Flaky tests detected in 85df3c4.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/26814187492
📝 Reported issues:

• [Flaky Test] shouldn't conflict with server-side autosave #78706 in /test/e2e/specs/editor/various/autosave.spec.js

[talldan]

Another option could be to make the block supports more granular.

The shortcode and HTML block could use config like this and the users then get back the ability to toggle the blocks:

// doesn't support viewport hiding, but supports 'everywhere' hiding.
supports.visibility = { viewport: false, everywhere: true }

false | true could be kept for shorthands for full or no support.

My understanding is that still works for those blocks because the 'everywhere' feature doesn't use css classnames, it completely skips rendering the block.

I don't like 'everywhere' as the term, but hopefully you get the general idea.

[ramonjd]

Thanks for dealing with this so quickly @t-hamano

The staggered checks LGTM

[t-hamano]

Thanks for the review!

I'm not yet convinced if this approach is ideal. If we are to move forward with this PR, I would like to submit a core PR.

After creating the core ticket and core PR, I would like to merge this PR.