Registration of custom blocks doesn't work when script put in the footer

[korobochkin]

Issue Overview

I am discovering Gutenberg source code and hope can contribute after diving into it. After attempt to create a new custom Guten block I found that the code on master branch (51b36b1, last version on March 16) doesn’t allow to create a new block.

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

This happens because editor runs before any 3rd party block can be registered. The following script from lib/client-assets.php runs the editor and renders editor with content. 3rd party blocks should be registered before initializeEditor call.

window._wpLoadGutenbergEditor = wp.api.init().then( function() {
	wp.blocks.registerCoreBlocks();
	return wp.editPost.initializeEditor( 'editor', window._wpGutenbergPost, editorSettings );
} );

Steps to Reproduce (for bugs)

1. Register your own custom block (for instance, you can use simple template).
2. Insert your new block into the editor. And ensure that it will be saved.
3. Reload the page. Checkout editor — your block will appear as core/freeform (TinyMCE) block. This happened because your custom block was registered after editor initial run and JS rendered any unknown blocks as core/freeform.
   Unknown block name sets in blocks/library/index.js:96.

Chrome Version 65.0.3325.162 (Official Build) (64-bit)
Safari Version 11.0.3 (13604.5.6)

I suppose that this is not browser related bug.

Expected Behavior

Custom blocks render as any other core blocks.

Current Behavior

Custom blocks render as core/freeform (TinyMCE) block, because custom blocks can't be registered before editor runs.

Possible Solution

Update PHP's function gutenberg_editor_scripts_and_styles from lib/client-assets.php. For example, relocate do_action( 'enqueue_block_editor_assets' ) which enqueues JS and CSS assets for 3rd party blocks. Move it before inline script which runs the editor. Not sure if it will work.

I suppose the best scenario is:

1. Load and setup all required JS & CSS for Gutenberg functionality.
2. Register core/* blocks.
3. Register 3rd-party-blocks/*.
4. Run the editor.

Related Issues and/or PRs

Todos

• Tests
• Documentation

[elenaskrotova]

Very important issue for plugins integration into Gutenberg structure

[gziolo]

I haven't run into this issue myself, but I suppose there might be some scenario where the order of registered scripts matters. We are looking into the blocks registration and should propose some improvements and possibly breaking changes in the next week or two.

[gziolo]

This is also a similar issue to #4848.

[korobochkin]

After investigation with @gziolo we found solution for this issue. There was problem that 3rd party script was included to the page in footer. So if you are registering your own block do not pass true to wp_register_script as 5th arg.

Correct:

wp_register_script(
   'your-script-name',
  $this->getBaseUrl() . 'assets/js/admin/guten-modules/guten-modules.bundle.js',
  array('wp-blocks', 'wp-element'),
  Plugin::VERSION
);

Wrong:

wp_register_script(
   'your-script-name',
  $this->getBaseUrl() . 'assets/js/admin/guten-modules/guten-modules.bundle.js',
  array('wp-blocks', 'wp-element'),
  Plugin::VERSION,
  true
);

[gziolo]

As discussed on Slack. This needs to be improved in the long run on the Gutenberg's side to give a freedom where to put the code inside your HTML code.

However for the time being it's recommended to avoid putting your plugin's code inside the footer. Sorry for the inconvenience.

[gziolo]

Given that there were other similar changes, it seems like:

So if you are registering your own block do not pass true to wp_register_script as 5th arg.

is the way to go.

[gziolo]

It should work now regardless of the location of the script (footer vs header) after #6448 got merged.