Framework: Make sure block assets are always registered before wp-edit-post script

[gziolo]

Description

Fixes #6443 and #5661.

Raised by @korobochkin:

You can register your new Guten block with wp.blocks.registerBlockType function call. But it won’t work after page reloading

Raised by @theleemon:

Everything seems to work as expected: at first glance the block is rendered correctly both on the editor and the frontend. But, if I save the post, then preview it and at the end I come back to edit it again, the custom block is automatically rendered in the editor as a classic editor block, although the HTML code beneath it shows that it's still a custom block. The console shows no errors.

In my tests it turned out that all blocks related assets are loaded too late when their are forced to be included in the footer. It works perfectly fine when they are included in the header. This patch moves those assets to be include before wp-edit-post which moves them in the flow to be always included first regardless where there are located.

How has this been tested?

Manually. I registered the plugin with block using the code snippet generated with WP-CLI as explained in https://wordpress.org/gutenberg/handbook/blocks/generate-blocks-with-wp-cli/. I also updated:

    wp_register_script(
        'movie-block-editor',
        plugins_url( $block_js, __FILE__ ),
        array(
            'wp-blocks',
            'wp-i18n',
            'wp-element',
        ),
-        filemtime( "$dir/$block_js" )
+        filemtime( "$dir/$block_js" ),
+        true
    );

to ensure it works also when the script is loaded in footer.

I added the test block and made sure it still loads properly when I refreshed the page.

Types of changes

Bug fix (non-breaking change which fixes an issue).

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.

[youknowriad]

What if a plugin enqueue blocks but also register a plugin depending on wp-edit-post module?

My proposal here is to add a JavaScript actiion registerBlocks called on domReach (the WP package). This way no matter the script loading order, the blocks will always be registered at the right moment.

[gziolo]

Good point. An alternative would be to put inline script which initializes the editor under their own name and make wp-edit-post its dependency.

[youknowriad]

What I had in mind is something like that:

wp.domReady( () => {
    wp.hooks.doAction( 'registerBlocks' );
    wp.editPost.initializeEditor();
} );

And ask plugin authors to move their registerBlockType calls too the registerBlocks action. I know it might be a bit late for that, so the current method should work as well, and we could warn if registerBlockType is called before the hook.

[gziolo]

471aedb - is not production ready :)

[youknowriad]

LGTM 👍

[gziolo]

Tested with npm run build.

Master

Branch

I couldn't notice any regressions.

[aduth]

Should it be up to the editor to decide the specific time it should be initialized? Or should the prerequisite of the initialization be considered by that which is initializing it (thinking outside the specific "WP + Plugins" context).

[youknowriad]

Good question. you mean moving this to client-assets instead. Sounds like a good idea.

[gziolo]

Now that you asked it this way, it sounds reasonable 😃
I fully focused on fixing the issue with blocks loaded too late and I didn’t think about it.
We will have to make dom-ready its own module but it would happen sooner or later anyway.