Patterns containing non-core blocks are losing styling in the Inserter with Gutenberg 13

[WhiteHeatherClub]

Patterns containing non-core blocks are losing styling moving from Gutenberg 12.9 to 13.0 in the Inserter - they are placed and display fine on the page Editor, it's the Inserter Previews that are affected.

This happens in either a classic theme (i.e. Twenty Twenty One) or FSE theme (Twenty Twenty Two)

Originally posted by @WhiteHeatherClub in #40305 (comment)

[carolinan]

Hi
Please include detailed information about the non-core blocks, such as the name of the block and plugin, so that we can try to reproduce the problem.

[WhiteHeatherClub]

Hi, I'm using Getwid blocks - in my case patterns are made with the Media & Text Slider, Section and Image Slider (but I'm guessing it would affect the others as well).

Also on this post #40305 another Dev is mentioning it is happening with AinoBlocks as well.

[ellenbauer]

I want to report the same issue, I loose all CSS styling of our AinoBlocks plugin (https://wordpress.org/plugins/aino-blocks/) blocks, as soon as I activate Gutenberg 13+, see screenshots below:

Gutenberg plugin 13.1.0 active with Aino Blocks and one of our premium themes, but you can use our Aino free theme (https://wordpress.org/themes/aino/) to replicate the issue as well:

As a comparison without the Gutenberg plugin active:

This is a major issue for us and I wonder how to solve it. Any kind of help or hint on what we can do to fix it would be greatly appreciated.

[ndiego]

I have been able to confirm.

Testing steps:

1. Ensure you are running 6.0 or Gutenberg 13+ is active
2. Install and activate the Aino theme
3. Install and activate Aino Blocks
4. Navigate to a new page and preview patterns in the Pattern Explorer, they will appear broken
5. Revert to 5.9.3 and disable Gutenberg
6. Preview the patterns again, and they will appear correctly

cc @Mamaduka @ntsekouras I am guessing this is related to the new patterns REST API "stuff", but could use your expertise.

cc @annezazu @priethor @gziolo @adamziel pinging you all for review, this is a significant breaking change that we need to get fixed before the 6.0 release.

[ndiego]

In investigating this more deeply, I do no believe this is related to the REST API patterns implementation. Block styles in the Aino Blocks plugin are enqueued in a single stylesheet with the enqueue_block_editor_assets hook. This was/is a very common implementation for adding custom styles in the Editor.

Something changed in 13.0+ and WordPress 6.0 where this is no longer working properly in Block Previews or the Site Editor. If you insert one of the Aino Patterns into a template in the Site Editor, they will also lack styles. See the screenshot below:

[Mamaduka]

#40469 might be related to this issue. Unfortunately, I couldn't track down the source of the problem.

[ndiego]

Thanks for pointing out #40469 @Mamaduka, I just tested that and confirmed that's also a major issue.

[ndiego]

@getdave yes, but they are not being loaded in the iframe where the pattern is rendering. This is true for the pattern previews as well as the Site Editor.

[gziolo]

I guess it means that it's an issue with how styles/scripts are registered for 3rd party blocks that aren't compatible with the iframed version of the editor. Based on the report from @getdave, it's clear that styles are present on the page, so it must be something with passing them through to the iframe.

[ndiego]

@gziolo could this code be related? #40278

[gziolo]

Yes, it would be this logic but previous PR. The one you shared only moves code between files. One thing we struggled with before Beta 1 was the same logic missing in WP Core which caused missing styles in iframed editors. In effect, block styles for core blocks worked only in the post editor.

[Mamaduka]

This is original PR that change asset resolving for iframed editors #37193.

[ndiego]

@Mamaduka that is what it seems like, but the issue only starts occurring in 13.0+. That PR looks to have been included in 12.2

[getdave]

Looking into this a bit...

I have the following code in a test plugin active on my Gutenberg 13 enabled site:

function myplugin_enqueue_block_editor_assets() {

	wp_enqueue_style(
		'davesmith-editor-css',
		plugins_url( 'test-editor.css', __FILE__ ),
		array( 'wp-edit-blocks' )
	);

	wp_enqueue_block_style(
		'core/paragraph',
		array(
			'handle' => 'davesmith-block-css',
			'src'    => plugins_url( 'test-block.css', __FILE__ ),
			'deps'   => array( 'wp-edit-blocks' ),
		)
	);

}
add_action( 'enqueue_block_editor_assets', 'myplugin_enqueue_block_editor_assets' );

Both are seen in the network tab so it looks like I'm enqueuing them correctly:

...but when I debug packages/edit-site/src/components/block-editor/resizable-editor.js, I find that neither settings.__unstableResolvedAssets nor settings.styles contains a reference to those enqueued styles.

Similarly a call to wp.data.select( 'core/edit-site' ).getSettings() in the console of the Site Editor reveals that the styles property of the settings object also doesn't contain a reference to the enqueued styles.

Here is where the unsableResolvedAssets is prepared:

gutenberg/lib/compat/wordpress-6.0/client-assets.php

Lines 102 to 109 in 3ce2c79

	add_filter(
	'block_editor_settings_all',
	function( $settings ) {
	// In the future we can allow WP Dependency handles to be passed.
	$settings['__unstableResolvedAssets'] = gutenberg_resolve_assets();
	return $settings;
	}
	);

...but gutenberg_resolve_assets doesn't appear to care about block styles that are registered outside of block.json.

gutenberg/lib/compat/wordpress-6.0/client-assets.php

Line 41 in 3ce2c79

function gutenberg_resolve_assets() {

[ndiego]

Thanks for digging into this. I am becoming more and more convinced it is related to #37193. It did not popup until 13.0 with 5.9.3, even though it was merged in 12.2, because of a missing backport that was never done: WordPress/wordpress-develop#2564 (comment). This backport was fixed, which seem to have then made the issue appear. That is my best guess at the moment.

[gziolo]

@getdave wp_enqueue_block_style was added to WP core 6 months ago with:
WordPress/wordpress-develop@f034bc8

I don't think it ever registered scripts/styles to the block type object in the registry.

[gziolo]

Thanks for digging into this. I am becoming more and more convinced it is related to #37193. It did not popup until 13.0 with 5.9.3, even though it was merged in 12.2, because of a missing backport that was never done: WordPress/wordpress-develop#2564 (comment). This backport was fixed, which seem to have then made the issue appear. That is my best guess at the moment.

Here is the commit where we backported changes from Gutenberg 12.2 to WordPress core: WordPress/wordpress-develop@1d086c5. It resolved the issue with styles for core block in the iframed editors.

I'm still not sure how this could work correctly with WordPress 5.9.3 and Gutenberg 12.1 and earlier, because the old handler looks similar.

[ellenbauer]

Thank you so much for all your help and digging into the issue further. Please let me know if I should make any changes to adding the patterns for testing. I would love to be able to help further.

[getdave]

@getdave wp_enqueue_block_style was added to WP core 6 months ago with:
WordPress/wordpress-develop@f034bc8

Ah my mistake. I'm sure I saw one of the reports mentioned that being used. Looking an Aino Blocks Plugin they are just using wp_enqueue_style hooked on enqueue_block_editor_assets so I'll focus on that.

[ndiego]

Last update for today. I have narrowed down the issue to something that changed in 13.0. The issue does occur in 6.0 Beta 1 without Gutenberg active. So some change happened between 12.9 -> 13.0 and 5.9.3 -> 6.0 that is causing this. I wish I could be more sure about the cause, but currently, everything is pointing to #37193. That said, that PR was merged in 12.2 and there are no styling issues with 12.2 and 5.9.3. The issues only begin at 13.0.

I will add more notes if I discover anything relevant, but more eyes are definitely welcomed. 🙏

[gziolo]

A potential fix is ready for testing: #40842.

[WhiteHeatherClub]

Thank you for such great work with fixing this. First Class!