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

Open
macemmek opened this Issue Sep 14, 2018 · 25 comments

Comments

Projects
None yet
@macemmek
Copy link

macemmek 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

This comment has been minimized.

Copy link
Contributor

youknowriad commented Sep 17, 2018

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

This comment has been minimized.

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

This comment has been minimized.

Copy link
Contributor

youknowriad commented Sep 17, 2018

@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

This comment has been minimized.

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

This comment has been minimized.

Copy link
Contributor

greatislander commented Nov 10, 2018

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

This comment has been minimized.

Copy link
Contributor

youknowriad commented Nov 12, 2018

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

@mahdiyazdani

This comment has been minimized.

Copy link
Contributor

mahdiyazdani commented Nov 22, 2018

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

@phpbits

This comment has been minimized.

Copy link

phpbits commented Dec 1, 2018

Same here. Tested and problem still exists. Thanks!

@phpbits

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Member

swissspidy commented Dec 9, 2018

@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

This comment has been minimized.

Copy link

carrieforde commented Dec 12, 2018

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

This comment has been minimized.

Copy link

drdogbot7 commented Dec 17, 2018

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

This comment has been minimized.

Copy link
Contributor

youknowriad commented Dec 18, 2018

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

kraftner commented Dec 19, 2018

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

@phpbits

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

SpencerCloud commented Jan 7, 2019

@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

This comment has been minimized.

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

This comment has been minimized.

Copy link

SpencerCloud commented Jan 8, 2019

It worked! Thank you both @lushkant @phpbits!

@scottblackburn

This comment has been minimized.

Copy link

scottblackburn commented Jan 15, 2019

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

@SpencerCloud

This comment has been minimized.

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

This comment has been minimized.

Copy link

scottblackburn commented Jan 15, 2019

Great, thanks @SpencerCloud !

@hamannjames

This comment has been minimized.

Copy link

hamannjames commented Jan 18, 2019

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 comment has been minimized.

Copy link

markhowellsmead commented Mar 22, 2019

This is still happening as of today with WordPress 5.1.1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.