If there is a block with apiVersion of 2 in block.json, the content width is applied to the pattern preview

[inc2734]

Description

For example, activate a plugin with apiVersion 2 blocks such as CoBlocks. The content width would then be applied to the content in the pattern preview.

Specifically, the following styles will be added in the pattern preview.

.editor-styles-wrapper .block-editor-block-list__layout.is-root-container > :where(:not(.alignleft):not(.alignright):not(.alignfull)) {
    max-width: 650px;
    margin-left: auto !important;
    margin-right: auto !important;
}

If the apiVersion is only a block of 3, this style will not be loaded.

Even without the block plugin installed, I was able to reproduce the problem by changing wp-includes/blocks/blocks-json.php as follows.

<?php return array(
  'archives' => array(
    '$schema' => 'https://schemas.wp.org/trunk/block.json',
    'apiVersion' => 2, // 3 to 2

Step-by-step reproduction instructions

1. Activate the appropriate block plugins. For example, CoBlocks
2. Open the Submission Editor
3. Open the Pattern Inserter
4. Check the preview

---

1. Modify wp-includes/blocks/blocks-json.php.
2. Open the Submission Editor
3. Open the Pattern Inserter
4. Check the preview

Screenshots, screen recording, code snippet

Kapture.2023-06-30.at.15.16.51.mp4

Environment info

• WordPress 6.3 beta2
• TwentyTwentyThree v1.1

This problem does not occur when the Gutenberg (v16.1.0) plugin is activated.

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[Mamaduka]

Probably related to the changes from #48286.

[ndiego]

Probably related to the changes from #48286.

@ellatrix would you be able to provide any insight into this one?

[carolinan]

Are we not expecting block developers to update to version 3 though?

[inc2734]

Updating to WordPress 6.3 beta3 resolved this issue!

[t-hamano]

The problem appears to exist in WordPress Beta3 as well. I tested with the nightly build version (WordPress 6.3-beta3-56143).

5a6a55fd00683975e47e16272b21c13a.mp4

[inc2734]

Updating to WordPress 6.3 beta3 resolved this issue!

Sorry!I had checked it in the site editor. For the post editor, it was not fixed even in WordPress 6.3 beta3.

[bgardner]

Worth noting that with Beta 4, I am still seeing this as an issue:

[bgardner]

In the site editor it is fine:

[bgardner]

Looks like the SVG Support plugin by 10up and Ninja Forms plugins were the culprits in my case. Both in isolation when active cause the content width to be not full width. I deactivated them both and see full width now in inserter:

[Mamaduka]

I'm still unable to reproduce the issue when the Gutenberg plugin is active. This makes debugging a bit harder.

One difference I noticed when testing WP 6.3-beta4 + apiVersion: 2 block without Gutenberg; I see a lot of style compatibility warnings when opening pattern explorer. I don't see these warnings when the Gutenberg plugin is active.

Can anyone confirm this behavior?

`compatStyle.id` was added to the iframe incorrectly. Please use block.json or enqueue_block_assets to add styles to the iframe.

[t-hamano]

Can anyone confirm this behavior?

I too can confirm that log. What I am a little concerned about is that if the apiVersion:2 block exists and the Gutenberg plugin is activated, the main editor becomes an iframe. My understanding is that the main editor should not be an iframe if the apiVersion:2 block is included, with or without the Gutenberg plugin, as was done in #48286. But I don't know if this is relevant to this issue 🤔

[Mamaduka]

There's a special check for the Gutenberg plugin, so I assume it's always enabled with a plugin for testing purposes. The code shipped in #48286.

gutenberg/packages/edit-post/src/components/visual-editor/index.js

Lines 362 to 365 in 388d3d4

	shouldIframe={
	( ( hasV3BlocksOnly ||
	( isGutenbergPlugin && isBlockBasedTheme ) ) &&
	! hasMetaBoxes ) ||

P.S. You can reproduce the same issue with the Gutenberg plugin active by enabling the meta boxes.

[Mamaduka]

You can consistently reproduce the issue with or without the Gutenberg plugin by enabling "Custom fields." It doesn't require a block - apiVersion: 2.

The problem is with the useCompatibilityStyles hook, which mistakenly copies global styles presets as compat styles when they are already rendered directly into the iframe.

Update: One way we can resolve this is to add "markers" to the style tags generated by the EditorStyles and LayoutStyle components, then skip these in the useCompatibilityStyles hook.

Why

• When the non-iframed editor is rendered, global style presets are injected into a body.
• The useCompatibilityStyles parses and memoized document stylesheet on initial load. So these styles are added to the compat styles array.
• The presets are copied as part of the compatibility layer when the iframed editor is rendered via pattern preview or switching device type. This results in "broken" previews and unnecessary warnings in the console.

[Mamaduka]

I just pushed proof-of-concept PR that solves the issue using the "markers" method I mentioned in my previous comment - #52640.