Gutenberg: Styles variations don't work for blocks using `InnerBlocks`

[macemmek]

Describe the bug
I'd like to create a custom section block with additional style variants. The section is going to be a wrapper for multiple blocks - so parent block with some inner blocks.
Unfortunately, an attempt of choosing styles triggers an error _Cannot read property 'innerBlocks' of null_
Maybe there's a bug or maybe I'm doing wrong.

To Reproduce
Create the block:
```const { __ } = wp.i18n;
const { registerBlockType } = wp.blocks;
const { InnerBlocks } = wp.editor;

export default registerBlockType(
'my-blocks/section',
{
title: __( 'My Section', 'my-blocks' ),
description: __( 'A section of blocks.', 'my-blocks' ),
category: 'layout',
icon: 'index-card',
keywords: [
__( 'Text', 'my-blocks' ),
__( 'Content', 'my-blocks' ),
__( 'Paragraphs', 'my-blocks' ),
],
styles: [
{ name: 'default', label: __( 'Regular', 'my-blocks' ), isDefault: true },
{ name: 'intro', label: __( 'Intro', 'my-blocks' ) },
],
edit: () => {
return (

);
},
save: () => {
return (

);
},
},
);

1. Insert the block "My Section" into the editor.
2. Click block switcher to choose between style variants.
3. The popup appears: "The editor has encountered an unexpected error.  Attempt Recovery  Copy Post Text  Copy Error"

The copied error is like below:

TypeError: Cannot read property 'innerBlocks' of null
at t.value (http://mysite.local/wp-content/plugins/gutenberg/build/editor/index.js?ver=1536831520:12:157572)
at t.value (http://mysite.local/wp-content/plugins/gutenberg/build/editor/index.js?ver=1536831520:12:157246)
at commitLifeCycles (http://mysite.local/wp-content/plugins/gutenberg/vendor/react-dom.24169eaf.js:14939:22)
at commitAllLifeCycles (http://mysite.local/wp-content/plugins/gutenberg/vendor/react-dom.24169eaf.js:16040:7)
at HTMLUnknownElement.callCallback (http://mysite.local/wp-content/plugins/gutenberg/vendor/react-dom.24169eaf.js:140:14)
at Object.invokeGuardedCallbackDev (http://mysite.local/wp-content/plugins/gutenberg/vendor/react-dom.24169eaf.js:178:16)
at invokeGuardedCallback (http://mysite.local/wp-content/plugins/gutenberg/vendor/react-dom.24169eaf.js:227:29)
at commitRoot (http://mysite.local/wp-content/plugins/gutenberg/vendor/react-dom.24169eaf.js:16181:7)
at completeRoot (http://mysite.local/wp-content/plugins/gutenberg/vendor/react-dom.24169eaf.js:17196:34)
at performWorkOnRoot (http://mysite.local/wp-content/plugins/gutenberg/vendor/react-dom.24169eaf.js:17141:9)
```

Expected behavior
Style variants to choose should appear without an error.

Additional context

• Gutenberg 3.8.0
• WordPress 4.9.8

[youknowriad]

This issue raises something interesting:

It's impossible to "preview" a block (Use <BlockPreview> component) if this block is a container block. The problem is related to how the <InnerBlocks> component work because it assumes the block is available in the editor while it's not the case when trying to preview a block that hasn't been inserted yet.

One potential solution is to change how InnerBlocks component work and instead of fetching the block from the state, we fetched from a context made available by the BlockEditProvider which also means BlockEdit should be refactored in the same way to accept a block object instead of a clientId.

Thoughts @aduth and others?

[aduth]

@youknowriad Would your idea also fall along the same lines of thinking of having an <Editor value={ [ /* ...blocks */ ] } /> component interface?

[youknowriad]

@aduth yep, right. I guess if we had <Editor value={blocks} /> we could refactor the <BlockPreview /> component to use it instead of using <BlockEdit />. We might have a small performance decrease because we need to go through init steps etc...

I guess it's related to #7453

[aduth]

Also worth noting that initial explorations of block nesting in #3745 created substores similar to what we're talking about here, which was eventually abandoned.

[greatislander]

Just to get a clearer sense of this, is it accurate to say that blocks with InnerBlocks do not support style variations at present?

[youknowriad]

Just to get a clearer sense of this, is it accurate to say that blocks with InnerBlocks do not support style variations at present?

That's true. I think we can provide a less than ideal fix for now until the root issue (which requires a big refactoring) is addressed.

What we can do right now, is to use an error boundary around the preview component as it should possible to use the style variation without the need to preview it.

[mahdiyazdani]

Tested with the latest version of the Gutenberg 4.5.1, but the problem still persists.

[phpbits]

Same here. Tested and problem still exists. Thanks!

[phpbits]

@youknowriad @aduth Are there any fixes available for this issue yet? With 5.0 already available we need to have this issue fixed in order to release our plugin. Do you have function that we can use to check if it's on preview? Like is_blockPreview or something. Thanks!

[swissspidy]

@phpbits There were no updates to this issue here, so no news. The error boundary suggestion is something that would need to be added in Gutenberg itself, I think.

[carrieforde]

I'd really love to see a fix for this. Adding styles to blocks with InnerBlocks has allowed me and my team to create unique variations on a block (for example, a set of steps) with nothing more than a classname change on the parent element. The main workaround we've been using is to manually add the class via the Advanced panel, but this isn't a very discoverable solution for our content team.

If there is anything I can do to get my hands dirty and help address this, please let me know--I'd love to help out.

[drdogbot7]

Is the problem just with the little previews that display in the Inspector? Those make a lot of sense for things like buttons, but not-so-much for large blocks.

Maybe the simplest solution would just be to have an option to disable/customize the previews in the style selector, as opposed to refactoring InnerBlocks.

for instance:

styles: [
    { name: 'default', label: _x( 'Regular', 'block style' ), isDefault: true },
    { name: 'large', label: _x( 'Large', 'block style' ) },
],
stylePreviews: FALSE

I would be fine with just having a fallback vanilla radio input or dropdown… after all the user will see the effects in the editor anyway.

[youknowriad]

I'd be fine with an error boundary and we fallback to "no-preview" when there's an error. If anyone has bandwidth for this, go for it.

[phpbits]

+1 for adding no-preview. I'm currently using ( typeof this.props.insertBlocksAfter !== 'undefined' ) which is working fine just to remove the error for now ;)

[kraftner]

@phpbits Can you elaborate on that fix? I don't get where/what you are doing to bypass the error.

[phpbits]

@kraftner It's seems that this.props.insertBlocksAfter returns undefined on styles preview, so to prevent the errors I chose to do this in order to not display InnerBlocks. I hope this make sense.

[torounit]

Error when clicking on Style Panel.

this.props.block is null.

https://github.com/WordPress/gutenberg/blob/v4.7.1/packages/editor/src/components/inner-blocks/index.js#L41
and
https://github.com/WordPress/gutenberg/blob/v4.7.1/packages/editor/src/components/inner-blocks/index.js#L55

[SpencerCloud]

@phpbits @kraftner Could you let me know where and how the code is implemented? Is this in an if statement somewhere, in the edit: function? I'm confused on where and how the implementation of ( typeof this.props.insertBlocksAfter !== 'undefined' ) prevents displaying InnerBlocks.

Much appreciated!

[lushkant]

@SpencerCloud Yes, it's just a conditional check in edit function, and let the save function load normally with <InnerBlocks.Content />.
Thanks @phpbits for this +1

[SpencerCloud]

It worked! Thank you both @lushkant @phpbits!

[scottblackburn]

@SpencerCloud Did you just wrap the <InnerBlocks /> in the edit?

[SpencerCloud]

@SpencerCloud Did you just wrap the <InnerBlocks /> in the edit?

Right. Here's an example of some code in an edit function that I used:

el( 'div', {},
  // Workaround logic for this bug https://github.com/WordPress/gutenberg/issues/9897
  ( 'undefined' !== typeof props.insertBlocksAfter ) ?
    el( InnerBlocks, {
      allowedBlocks: [
        'core/columns',
        'core/button',
      ],
    } ) : el( 'div' )
),

There may be a better way to do it, but that's what worked for me.

[scottblackburn]

Great, thanks @SpencerCloud !

[hamannjames]

Wanted to comment and ask if this is being looked at? It seems like a pretty significant bug. I'd love to have options for styling my container blocks without having to rely on people pasting in classnames

[markhowellsmead]

This is still happening as of today with WordPress 5.1.1.

[hrsetyono]

If anyone wants to disable Preview Style in core/columns, here's the snippet:

  var el = wp.element.createElement;
  var allowColumnStyle = wp.compose.createHigherOrderComponent( function( BlockEdit ) {
    return function( props ) {
      var content = el( BlockEdit, props );

      if( props.name === 'core/columns' && typeof props.insertBlocksAfter === 'undefined' ) {
        content = el( 'div', {} );
      }

      return el(
        wp.element.Fragment, {}, content
      );
    };
  }, 'allowColumnStyle' );

  wp.hooks.addFilter( 'editor.BlockEdit', 'my/gutenberg', allowColumnStyle );

Put it in the same JS file where you call registerBlockStyle().

Basically whenever we want to show a Preview (either in Main Editor or Styles), it triggers editor.BlockEdit filter.

When creating preview for Styles, props.insertBlocksAfter is undefined. We thus override the content to empty div.

[nicpelletier]

I think this is even more important with the introduction of the Group bloc.

[strarsis]

+1, just encountered it with the Group block and with the Description List block.

Currently I have to manually set the class of block (Advanced tab, Additional CSS Class, is-style-[...]).

[hamannjames]

Squeaky wheel gets the grease adding another comment.

[mevanloon]

This error, exactly as described by @macemmek, just reared its head again. I'm running 5.2.2, fresh install, and trying to register a style for the core/cover block (I can also reproduce it with a self-made blocktype that uses InnerBlocks). When I click on styles the editor crashes, yielding the following message in the console:

TypeError: null is not an object (evaluating 'this.props.block.innerBlocks')
value — block-editor.min.js:55:124070
qi — react-dom.min.js:130:216
ui — react-dom.min.js:133:323
(anonymous function) — react-dom.min.js:158:380
unstable_runWithPriority — react.min.js:27
Vc — react-dom.min.js:158:363
Sc — react-dom.min.js:158:147
Z — react-dom.min.js:156:495
ah — react-dom.min.js:159:229
xf — react-dom.min.js:40
xf

Times the amount of styles registered. I've got a couple of sites that use styles like this, and I think this might be a regression somewhere.

[youknowriad]

@mevanloon It's fixed in the plugin but it's not shipped yet in WordPress Core.

[hamannjames]

@youknowriad What is the usual timeframe between fixes to the plugin and implementation in WP Core?

[youknowriad]

That depends on the timeframe of the major Core releases. Core doesn't follow a strict schedule. Here's the planning for the next one. https://make.wordpress.org/core/2019/08/07/wordpress-5-3-planning-roundup/

[mevanloon]

Thanks @youknowriad, glad to know I'm not going mad. I'll just wait for the proper release then.

[laras126]

I'm experiencing the same problem when adding a block style to the core/cover block via wp.blocks.registerBlockStyle. I am able to apply the style successfully _before_ uploading an image, but when I open the "Change block style or type" panel after an image has been uploaded, the fatal error described above occurs.

[mbruschi]

Unfortunately I've experienced the same error while registering Block Styles for core/columns.

Here is how it's done

wp.blocks.registerBlockStyle( 'core/columns',
    // [
    //  {
    //      name: 'default',
    //      label: 'has-no-background-color',
    //      isDefault: true,
    //  },...

The error code

TypeError: Cannot read property 'innerBlocks' of null
    at t.value (http://webshop.localhost/wp-includes/js/dist/block-editor.min.js?ver=2.0.3:55:124070)
    at qi (http://webshop.localhost/wp-includes/js/dist/vendor/react-dom.min.js?ver=16.8.4:130:198)
    at ui (http://webshop.localhost/wp-includes/js/dist/vendor/react-dom.min.js?ver=16.8.4:133:320)
    at http://webshop.localhost/wp-includes/js/dist/vendor/react-dom.min.js?ver=16.8.4:158:377
    at unstable_runWithPriority (http://webshop.localhost/wp-includes/js/dist/vendor/react.min.js?ver=16.8.4:27:36)
    at Vc (http://webshop.localhost/wp-includes/js/dist/vendor/react-dom.min.js?ver=16.8.4:158:360)
    at Sc (http://webshop.localhost/wp-includes/js/dist/vendor/react-dom.min.js?ver=16.8.4:158:144)
    at Z (http://webshop.localhost/wp-includes/js/dist/vendor/react-dom.min.js?ver=16.8.4:156:492)
    at ah (http://webshop.localhost/wp-includes/js/dist/vendor/react-dom.min.js?ver=16.8.4:159:227)
    at xf (http://webshop.localhost/wp-includes/js/dist/vendor/react-dom.min.js?ver=16.8.4:40:45)