Editor: Hide block editor warnings for pattern previews

[yogeshbhutkar]

What, Why and How?

This PR addresses the issue of warning interactive elements being displayed within IFrame Previews in the Preview Components. It was concluded that these warnings are not required to be rendered in Previews. This change hides the warnings to improve the IFrame Previews' visual consistency and user experience.

Testing Instructions

1. Go to the Site editor > Patterns > and edit one of your custom patterns under 'My patterns'.
2. Switch the editor to the 'code' view and alter the markup to intentionally make one of the pattern's block invalid.
3. Switch the editor back to the 'visual' view.
4. Observe the editor renders the Block contains unexpected or invalid content. warning.
5. Click 'Open navigation' at the top left of the screen and go to 'My patterns'.
6. Observe the pattern card preview do not render the Warning in the preview.

Screenshots

Before	After

Before	After

Closes: #68131

[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.

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

Co-authored-by: yogeshbhutkar <yogeshbhutkar@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: afercia <afercia@git.wordpress.org>
Co-authored-by: karmatosed <karmatosed@git.wordpress.org>

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

[yogeshbhutkar]

Thanks for the review @Mamaduka. Incorporated the suggested changes in the latest commit.

[t-hamano]

#68131 suggests hiding all interactive elements from the pattern preview. For example, should we hide placeholders in the Query Loop block as well?

[yogeshbhutkar]

I’ve implemented a change in the latest commit to hide all the placeholders except the media placeholders. The media placeholders are quite widely used to represent an insertable image and in my opinion should not be removed from the previews as well.

Example:

Before	After

I've tried demonstrating this with Group and Query Block Placeholders.

CC: @t-hamano

[Mamaduka]

I'm not sure about the placeholders. They could signal that the template/pattern needs to be finished. We shouldn't hide too much content and diverge previews from edit canvas.

cc @afercia, @karmatosed

[afercia]

We shouldn't hide too much content and diverge previews from edit canvas.

Ideally, previews should show what is rendered once 'finished' i.e. how the pattern will actually look like on the front end. The whole purpose of the preview cards is to allow users to choose a pattern based on functionality and design. Previews that show the editing UI don't make much sense to me.

[t-hamano]

What do you think about a JS approach?

That is, add the following changes to the BlockListBlockProvider component:

diff --git a/packages/block-editor/src/components/block-list/block.js b/packages/block-editor/src/components/block-list/block.js
index 29f8a97b03..9046774ee8 100644
--- a/packages/block-editor/src/components/block-list/block.js
+++ b/packages/block-editor/src/components/block-list/block.js
@@ -761,6 +761,10 @@ function BlockListBlockProvider( props ) {
                return null;
        }
 
+       if ( isPreviewMode && ! isValid ) {
+               return null;
+       }
+
        const privateContext = {
                isPreviewMode,
                clientId,

This approach can be extended to other block placeholders etc if needed.

export default function Edit() {
	const isPreviewMode = useSelect( ( select ) => {
		return select( blockEditorStore ).getSettings().isPreviewMode;
	}, [] );

	if ( isPreviewMode && someCondition ) {
		return null;
	}

	// ...
}

[Mamaduka]

What do you think about a JS approach?

That would increase the number of changes we'll have to make. Placeholder examples can introduce unnecessary block editor store subscriptions, which affects loading and typing performance. I'm trying to revert something similar via #68690 in favor of CSS.

[yogeshbhutkar]

I believe I’ve addressed all the feedback provided so far. Since the PR is still awaiting approval, is there anything else I need to do on my end?