Describe the bug
I have a custom block that uses objects from wp.components and wp.editor like RangeControl and InspectorControls. I'm getting errors in 5.0 beta 1 in the editor such as this:
The editor has encountered an unexpected error.
Uncaught TypeError: Cannot read property 'RangeControl' of undefined
Checking the console, it's clear that wp.components and wp.editor are both present. But it's like my custom blocks are ran first before the dependencies.
There's no error if the Gutenberg plugin 4.1 is used instead.
The fix for beta 1 that I tried is to include wp-components and wp-editor as dependencies upon enqueuing the custom blocks. Doing that seems to get rid of the error, but again, the error isn't present outside 5.0 beta 1
To Reproduce
Steps to reproduce the behavior:
Expected behavior
No errors
Desktop (please complete the following information):
@bfintal Experiencing the same issue with several custom blocks i've created. Can you go into detail on how you includes them as "dependencies upon enqueuing the custom blocks"?
@dimensionmedia When you enqueue the JS script that registers the custom blocks, just add wp-components and wp-editor to the wp_enqueue_script function's dependency parameter:
wp_enqueue_script(
'my-custom-block-js',
plugins_url( '/dist/blocks.build.js', dirname( __FILE__ ) ),
array( 'wp-blocks', 'wp-i18n', 'wp-element', 'wp-components', 'wp-editor' ),
true
);
@dennyf thank you. it's been so long since i've seen that part of my code, I was drawing a blank. I confirmed that I'm no longer getting the JS errors and assume for now this is an accepted solution but will continue to monitor.
Similarly, styles which are enqueued via wp_enqueue_style with a dependency for wp-blocks now do not work. The fix is to remove all dependencies for it.
wp_enqueue_style(
'my-custom-style-css',
plugins_url( 'dist/blocks.style.build.css', dirname( __FILE__ ) ),
array()
);
Confirming that this also happens in WordPress 5.0-beta2-43845, and that (in my plugin's case) adding wp-components and wp-editor to the enqueue as dependencies fixes the problem: https://github.com/INN/super-cool-ad-inserter-plugin/pull/41/commits/1c9202cd3c5a3f64644b1907d397e15d920f5bba
Noting that bugs that happen in WordPress 5.0 and that do not happen for the Gutenberg plugin should be reported in https://core.trac.wordpress.org/
I wanted to help test before moving the issue but I was unable to reproduce the problem and wanted to check in with you.
First, I tested by installing and activating Stackable – Ultimate Gutenberg Blocks 1.4 on WordPress 5.0-beta3-43865 and opening a post for editing and I did not see any errors. I did noticed that the 1.4 changelog mentions fixing invalid script and style dependencies though.
Next, I installed and activated Super Cool Ad Inserter Plugin 0.2 on WordPress 5.0-beta3-43865 and manually created an add as a widget and I was able to see the ad display on a test post and did not see any errors in the browser console.
@bfintal @benlk since it appears you were able to address the problems, can this issue be closed?
@designsimply I believe so; this issue is caused by plugin developers not declaring dependencies where Gutenberg-as-plugin had enqueued those dependencies by default.
Cheers @benlk and thanks for the quick reply!
Cross-referencing another similar report from WP 5.0 in case it's helpful to someone else later! https://core.trac.wordpress.org/ticket/45219
@designsimply @benlk Thanks! Yup I've addressed the problem. However, I think this might mean that the handbook should have more notes regarding dependencies https://wordpress.org/gutenberg/handbook/blocks/writing-your-first-block-type/
Most helpful comment
@dimensionmedia When you enqueue the JS script that registers the custom blocks, just add
wp-componentsandwp-editorto thewp_enqueue_scriptfunction's dependency parameter: