Plugins can't use block filters in the editor when Jetpack is enabled

[notnownikki]

Description

Jetpack enqueues scripts that depend on wp-blocks. When we have plugins that need to register filters used by wp-blocks, they end up loading and running after Jetpack, which has loaded wp-blocks and so the filters aren't registered in time to run.

Steps to reproduce the issue

This uses my WIP PR for extending the embed blocks to highlight the issue, but it should be reproducable with a simpler plugin, look at the extend-embeds plugin in the PR.

1. Check out the PR at WIP - Allow plugins to extend core embed blocks WordPress/gutenberg#14050 which enables embed block extensions, and enable the extend-embeds plugin
2. Start a new post and embed the following URL by pasting it: https://www.reddit.com/r/stevenuniverse/comments/ax0u5i/innocence/ This will trigger the test plugin's behaviour, and you'll see a very boring "custom preview" message, and the block will be "Reddit with extra stuff"
3. Abandon the post, go enable Jetpack
4. Start a new post, embed the same URL, and you'll see the custom preview no longer works.

Analysis so far

This doesn't seem specific to this code or plugin. Scrips that need to load before wp-blocks end up loading after the code in wp-blocks has been run, once Jetpack is enabled, because Jetpack has already required it.

The test plugin in the PR enqueues its scripts like this:

function extend_embeds_init() {
	wp_enqueue_script(
		'gutenberg-test-extend-embeds',
		plugins_url( 'extend-embeds/index.js', __FILE__ ),
		array(
			'wp-element',
			'wp-editor',
			'wp-i18n',
		),
		filemtime( plugin_dir_path( __FILE__ ) . 'extend-embeds/index.js' ),
		true
	);
	add_action( 'rest_api_init', 'extend_embeds_rest_api_init' );
}
add_action( 'init', 'extend_embeds_init' );

That works when Jetpack isn't present, the script is loaded before wp-blocks and registers the filter before the core blocks are registered, allowing the plugin to use the hooks that wp-blocks uses.

There isn't a way (that I can see) to say "make sure this loads BEFORE wp-blocks" and so when Jetpack does this in class.jetpack-gutenberg.php

		wp_enqueue_script(
			'jetpack-blocks-editor',
			$editor_script,
			array(
				'lodash',
				'wp-api-fetch',
				'wp-blob',
				'wp-blocks',
				'wp-components',
				'wp-compose',
				'wp-data',
				'wp-date',
				'wp-edit-post',
				'wp-editor',
				'wp-element',
				'wp-hooks',
				'wp-i18n',
				'wp-keycodes',
				'wp-plugins',
				'wp-rich-text',
				'wp-token-list',
				'wp-url',
			),
			$version,
			false
		);

then wp-blocks before Jetpack's blocks/editor.js, and it's too late for other plugins to do what they need to do.

[jeherve]

cc @ockham, our block registration master :)

[notnownikki]

I just rebased the PR where I'm seeing this issue, and it's only happening for admin users. Authors and editors, no problems at all.

[ockham]

I just rebased the PR where I'm seeing this issue, and it's only happening for admin users. Authors and editors, no problems at all.

I just tried to repro this and see it for admins, editors, and authors alike.

Your analysis makes a lot of sense, but wouldn't that mean that it should be up to Gutenberg to prevent that something like this happens? (I.e. running wp-blocks before relevant filters are run)

In other words, is this an instance of WordPress/gutenberg#9757?

[notnownikki]

Yes, it does seem to be that behaviour.

Ok, I'll have to come up with a workaround. Thanks for looking into it.