Adding a classic block inside a columns block causes a block validation failure.

[vitozgonik]

Hello, I came across an issue with Columns Block when Classic Block is added. Follow the below steps in WordPress Admin to reproduce.

1. Add Columns Block into a page
2. Add Classic Block into one of the columns
3. Add some copy into the Classic Block
4. Save page

The below console error appears
Block validation: Block validation failed for core/column

Is there a workaround for this issue as this is currently blocking my progress of building a website?

Thanks :)

[youknowriad]

The fact that the classic block is a block without delimiters makes it impossible to use in nested contexts.

Maybe we should remove it from all nested contexts or just find a way to add the delimiters in this case. cc @aduth

[aduth]

Comment delimiters for a classic block are valid, and I expect would be parsed correctly (as valid block, even?). The challenge there is in implementing these changes to the serializer, which is unaware of a context in which a block lives (i.e. nesting):

gutenberg/packages/blocks/src/api/serializer.js

Lines 254 to 277 in e969954

	/**
	* Returns the content of a block, including comment delimiters, determining
	* serialized attributes and content form from the current state of the block.
	*
	* @param {Object} block Block instance.
	*
	* @return {string} Serialized block.
	*/
	export function serializeBlock( block ) {
	const blockName = block.name;
	const saveContent = getBlockContent( block );
	switch ( blockName ) {
	case getFreeformContentHandlerName():
	case getUnregisteredTypeHandlerName():
	return saveContent;
	default: {
	const blockType = getBlockType( blockName );
	const saveAttributes = getCommentAttributes( blockType, block.attributes );
	return getCommentDelimitedContent( blockName, saveAttributes, saveContent );
	}
	}
	}

The messaging around use-case of Classic block being a proper block or a fallback could impact which solution is best. If it's purely meant as a legacy interoperability, I think it'd be reasonable to omit from the inserter, and perhaps even from any inserter. Has this been considered previously?

[youknowriad]

I don't think it has been considered before. I know some people use it as the main block, I'd worry about removing from all inserters. Can we start by removing it from nested inserters (rootClientId is defined)?

[aduth]

Just seems to me like inconsistent messaging.

• If it's a block which I'm expected to be using, why can't I use it in a nested context?
• If it's not a block which I'm expected to using, why can I use it from a non-nested context?

[JakeQZ]

Preceding relevant console message (copied here to help those searching for existing known issues):

Block validation: Expected token of type EndTag ( Object { type: "EndTag", tagName: "div" } ), instead saw StartTag ( Object { type: "StartTag", tagName: "p", attributes: [], selfClosing: false } ).

[bucketpress]

Just seems to me like inconsistent messaging.

* If it's a block which I'm expected to be using, why can't I use it in a nested context?

* If it's not a block which I'm expected to using, why can I use it from a non-nested context?

Yes, the classic block is very much needed and nesting should work - until we can replicate its functions in other text blocks like list, heading and paragragh blocks:

• Text Color changes to specific characters (crucial)
• Inserting special characters (not as crucial since users can still so by copying and pasting from their own source)

And of course, there will be users who prefer to have a whole chuck of text in one block, instead of the current gutenberg implementation where each heading and paragraph and list is a separate block.

• use case: 20 block paragraphs vs 1 gutenberg classic where the user wants to change text alignment from left to right to all of the paragraphs. The user would have to change each paragraph block, as opposed to a single select and click for the classic block.

[youknowriad]

This issue is becoming a bit higher priority with the introduction of the Group block.

[flexerd]

Are there any Gutenberg team members looking into this? I am seeing some chatter on this bug. It's also breaking some other plugins such as Grids: Layout builder for WordPress. Advance Custom Fields' WYSIWYG editor works in columns as a block, I know the Classic Editor Block is not the same as the ACF WYSIWYG block but there might be some code we can look at?

[talldan]

A few more reports of this on #14958, #16186 and #16192, that I've closed as duplicate. I'll rename this issue so that others can find it more easily.

[rbsmidt]

Just want to add in on this one. If it really isn't a plan to make core/freeform work as a nested block in a core/column-block it should be explained somewhere in the docs.
However i would argue that a fix to the issue allowing core/freeform as a nested block of core/column would be more usable. My experience in setting up gutenberg blocks for clients is, that rich text editors are really a core block in almost any template or post type. Not being able to use it in a nested context seems like a hurdle!

[QuietNoise]

Some takes from loose survey amongst my clients.

• Everyone who ported from WP 4 to 5 and uses Gutenberg does use Classic editor instead of or beside Paragraph / Heading.
• Everyone who does more than a simple layout does intend to use Classic editor in the container (with above mentioned results though).
• Main reasons they stay away from Paragraph is because of it’s formatting limitations and de-encapsulation of a blurb content.

This issue (which - let me reiterate it again - cannot be fixed / bypassed / circumvented in any way by content admin when it occurs) together with other block validation errors cropping occasionally without particular reason are a main cause that I’m getting numerous requests from clients to consider implementing alternative block building plugins on their site.

It hurts because I consider Gutenberg a step forward and a way to break from overengineered visual builders, however I can’t blame them if Gutenberg experience is for them more bothersome than anything else they played with before.

My opinion. This should be made a critical issue and together with discussion about block validation #7604 should be prioritised. These are main reasons people are getting frustrated with G.

[weshinsley]

Totally agree with @QuietNoise - this bug is a crippling one; as a usually lower level web programmer looking into WP, it steers me away entirely, because of the immense challenge in doing something really quite easy to just write in HTML - putting some formatted text next to a leaflet map. It's proven impossible to achieve - or at least impossible to edit having achieved it once. The Classic Block is the only block providing the necessary formating options, and it works briefly - but as soon as you leave the editor page, it enters the "invalid state", none of the "Convert to HTML" or "Convert to block" buttons do anything, even deleting the block is impossible. I have to drop to code level and manually delete the chunks and start over.

[QuietNoise]

I've tested the fix with Gutenberg 6.2.0 and works flawlessly for new containers with Classic editor.
However, it doesn't fix blocks which are already marked as invalid.
None of the provided in GUI recovery options seem do anything (Convert to HTML, Convert to Blocks, Convert to Classic Block, Attempt Block Recovery are just mute buttons and do nothing, not even a console error).

I have hundreds of those broken blocks across many site and I wonder if there is a way to restore them without manually re-entering from source.