Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Styles variations don't work for blocks using InnerBlocks #9897

Closed
pshemek opened this issue Sep 14, 2018 · 37 comments · Fixed by #15561
Closed

Styles variations don't work for blocks using InnerBlocks #9897

pshemek opened this issue Sep 14, 2018 · 37 comments · Fixed by #15561
Labels
[Feature] Nested / Inner Blocks Anything related to the experience of nested/inner blocks inside a larger container, like Group or P [Feature] Theme Style Variations Related to style variations provided by block themes [Priority] High Used to indicate top priority items that need quick attention [Type] Bug An existing feature does not function as intended
Milestone

Comments

@pshemek
Copy link

pshemek commented Sep 14, 2018

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 { 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 (
				<InnerBlocks />
			);
		},
		save: () => {
			return (
				<div>
					<InnerBlocks.Content />
				</div>
			);
		},
	},
);
  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
Copy link
Contributor

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?

@youknowriad youknowriad added the [Type] Bug An existing feature does not function as intended label Sep 17, 2018
@aduth
Copy link
Member

aduth commented Sep 17, 2018

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

@youknowriad
Copy link
Contributor

@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
Copy link
Member

aduth commented Sep 17, 2018

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
Copy link
Contributor

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
Copy link
Contributor

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.

@youknowriad youknowriad changed the title Error with style variants applied to the block (parent) with InnerBlocks inside (Cannot read property 'innerBlocks' of null) Styles variations don't work for blocks using InnerBlocks Nov 12, 2018
@swissspidy swissspidy added the [Feature] Nested / Inner Blocks Anything related to the experience of nested/inner blocks inside a larger container, like Group or P label Nov 12, 2018
@mahdiyazdani
Copy link
Contributor

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

@phpbits
Copy link
Contributor

phpbits commented Dec 1, 2018

Same here. Tested and problem still exists. Thanks!

@phpbits
Copy link
Contributor

phpbits commented Dec 8, 2018

@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
Copy link
Member

@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.

@swissspidy swissspidy added the [Feature] Theme Style Variations Related to style variations provided by block themes label Dec 9, 2018
@carrieforde
Copy link

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
Copy link

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
Copy link
Contributor

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.

@youknowriad youknowriad added this to the Future: 5.x milestone Dec 18, 2018
@phpbits
Copy link
Contributor

phpbits commented Dec 18, 2018

+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
Copy link

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

@phpbits
Copy link
Contributor

phpbits commented Dec 19, 2018

@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.

@SpencerCloud
Copy link

@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
Copy link

lushkant commented Jan 8, 2019

@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
Copy link

It worked! Thank you both @lushkant @phpbits!

@scottblackburn
Copy link

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

@SpencerCloud
Copy link

SpencerCloud commented Jan 15, 2019

@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
Copy link

Great, thanks @SpencerCloud !

@hamannjames
Copy link

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
Copy link

This is still happening as of today with WordPress 5.1.1.

@hrsetyono
Copy link

hrsetyono commented Mar 31, 2019

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
Copy link

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

@youknowriad youknowriad added the [Priority] High Used to indicate top priority items that need quick attention label Apr 18, 2019
@strarsis
Copy link
Contributor

strarsis commented Apr 23, 2019

+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
Copy link

Squeaky wheel gets the grease adding another comment.

@mevanloon
Copy link

mevanloon commented Aug 16, 2019

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
Copy link
Contributor

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

@hamannjames
Copy link

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

@youknowriad
Copy link
Contributor

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
Copy link

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

@laras126
Copy link
Contributor

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
Copy link

mbruschi commented Mar 5, 2020

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)

@hannahmwool
Copy link

Was there ever a resolve here? I get the issue when trying to register a block style for media-text
wp.blocks.registerBlockStyle( 'core/media-text', [ { name: 'padded-background', label: 'Padded Background', } ] );

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Nested / Inner Blocks Anything related to the experience of nested/inner blocks inside a larger container, like Group or P [Feature] Theme Style Variations Related to style variations provided by block themes [Priority] High Used to indicate top priority items that need quick attention [Type] Bug An existing feature does not function as intended
Projects
None yet