CoBlocks: Correct example image URLs.

[kwight]

This PR filters certain CoBlocks settings to correct example image URLs.

Testing instructions

1. Sandbox the API and widgets.wp.com.
2. Build the wpcom-block-editor app from this branch, and transfer to your sandbox.
3. Bust the cache by entering a dummy value for $__autogen_cache_buster_wpcom_block_editor.
4. Start a new post in the block editor for a sandboxed test site.
5. Click the inserter in the top control bar, and hover over each of the three affected blocks: Masonry, Stacked, and Logos.
6. Ensure example images load properly in the preview to the right.

Fixes #37096

[matticbot]

Test live: https://calypso.live/?branch=fix/coblocks-previews

[matticbot]

This PR does not affect the size of JS and CSS bundles shipped to the user's browser.

Generated by performance advisor bot at iscalypsofastyet.com.

[kwight]

Server-side changes: D34792-code.

[kwight]

Updated this to no longer rely on server-side changes.

[kwight]

This isn't working at the moment; I don't think any blocks are passing the initial checks in getCoBlocksExampleImages.

[kwight]

It looks like CoBlocks blocks aren't registered at the time the filter is called; logging every name that goes through getCoBlocksExampleImages seems to list every block but CoBlocks blocks. I wonder if this super late registration on init (priority 99) affects things.

[mmtr]

I wonder if this super late registration on init (priority 99) affects things.

I think it's actually this registration, but yeah it's the same problem (scripts enqueued on init rather than on enqueue_block_assets, which is where our wpcom-block-editor/common script gets registered).

[gwwar]

If it's that much of an issue, we can maybe dispatch to the redux store on dom ready or unstable editor init, but it's not ideal.

[kwight]

For comparison, our own FSE plugin register blocks on init with priority 100 (¯_(ツ)_/¯), and the a8c/posts-list block goes through this filter, so there's something deeper going on here – I'll need to keep digging.

[mmtr]

For comparison, our own FSE plugin register blocks on init with priority 100 (¯_(ツ)_/¯), and the a8c/posts-list block goes through this filter, so there's something deeper going on here – I'll need to keep digging.

Note that we have dynamic blocks (server-side rendered) and regular blocks (full JS).

Dynamic blocks need to be registered with register_block_type in PHP, and this can be done in the init PHP hook. These blocks don't alter the regular blocks registered with JS, and thus don't trigger the blocks.registerBlockType JS hook. FSE blocks registered on init are dynamic blocks, so this is expected. Actually, a8c/posts-list is not registered there, since that block is not a dynamic block.

On the other hand, regular blocks are registered with registerBlockType in JS, which do trigger the blocks.registerBlockType JS hook. These scripts registering those blocks need to be enqueued on the enqueue_block_editor_assets hook. FSE also does this.

CoBlocks also have dynamic blocks and regular blocks. Dynamic blocks are registered on init, which is correct. However, scripts registering regular JS blocks are enqueued on init, which is incorrect - they should be enqueued on enqueue_block_editor_assets.

[kwight]

However, scripts registering regular JS blocks are enqueued on init, which is incorrect - they should be enqueued on enqueue_block_editor_assets.

I just noticed that the script is not even being enqueued there, it's just being registered (although it's obviously enqueued somewhere, because we still get our regular blocks registered). Trying the obvious stuff of switching to wp_enqueue_script, making gutenberg_wpcom_enqueue_scripts on a later priority, and adding coblocks-editor as a dependency for gutenberg-wpcom-common don't seem to make a difference.

[mmtr]

Noting that this won't be needed once we activate 1.17.1 on production since the previews use now images hotlinked from Wikimedia Commons.

[kwight]

Closing in favour of the upcoming 1.17.1-wpcom – see #37096 (comment).