{ skipBlockValidation: true }

[braco]

Gutenberg currently invalidates blocks whose layout has changed in any way between save and edit, with a severe error message:

this block contains unexpected or invalid content

This is confusing and irritating during block development and is outright crippling for different use cases like a corporate CMS managing a large library of React components.

The current solution is to deprecate blocks with an array of older versions of the block, which is a huge amount of work, not realistic at scale, and completely unnecessary for most situations.

Another suggestion has been to use server rendering via render_callback, but this pushes everything to PHP and out of React, which creates a ton of complications.

All of this would be moot if Gutenberg just respected a block requesting control over its own layout via:

{ skipBlockValidation: true }

or something like

{ automaticallyUpgradeBlock: true }

This could be paired with disabling HTML editing for that block.

Blocks under this configuration should be considered attribute-first and not layout-first.

This is a big missed opportunity for a broad set of applications.

See also:
#7604
#10444

[swissspidy]

This sounds very dangerous as people might mis-use this by just leaving skipValidation in their blocks instead of properly using the deprecation feature. You'd basically shoot yourself in the foot by making it harder to update the block markup in the future.

[braco]

Hi @swissspidy, thank you for the response.

I don't follow on how it would be harder to update the block markup in the future as long as the attributes are preserved across markup changes, can you explain that?

I don't need or want to use the deprecation feature, and the Gutenberg interface serves only to capture structured input from the user in a WYSIWYG manner. Development is currently needlessly complicated and the proposed solutions (render_callback) are terrible. I can see your point in the context of third party plugins being consumed by hapless users, but not for a controlled environment / corporate CMS, and not for other use cases like some forms of dynamic content.

[maxxwv]

I swear this conversation was part of another issue earlier, but it's late so I could be mistaken.

Either way, the fact that Gutenberg relies on compiled markup as the overall source of truth is - sorry to say it - but it's completely ridiculous. The data is the important part, not the display. If you're going to look to a central source of truth, it should be the attributes and/or state, not the output markup. This way of doing things has lead to numerous headaches with even something so simple as just formatting a decimal number output for me and my team already.

[fklein-lu]

This sounds very dangerous as people might mis-use this by just leaving skipValidation in their blocks instead of properly using the deprecation feature. You'd basically shoot yourself in the foot by making it harder to update the block markup in the future.

Deprecating blocks is not an adequate mechanism for evolving the HTML of a block. Gutenberg continuously shoots itself in the foot by validating HTML.

At Human Made, we have been using Gutenberg since the early 2.x versions, and already before 5.0 was released we were hitting the limitations of the block validation a lot. This was pointed out to the project leads as part of early agency adopter feedback, and it was ignored.

In fact we have a project where most blocks now have deprecated versions, some are even up to the third deprecation. And this is not even a website that gets a lot of maintenance work. We have another project, with 18 custom blocks, and more to come and not a single one is uses the JavaScript save() method.

This issue boils down to a fundamental flaw in how Gutenberg was designed, as @maxxwv has pointed out. PHP rendered blocks are just a way to work around this limitation, but it has severe drawbacks, as nothing gets saved into the post content. Therefore as far as things like search are concerned, there is no content produced by the block.

The proposed API change is a possibility, however what really would need to happen is this:

• If a block does not use attribute storage in HTML, Gutenberg should not try and validate the block. There's no reason to.
• If a block stores attributes in HTML, and Gutenberg is able to successfully extract them, then there should be no further validation. Because the edit view now has everything that is needed to work, meaning the data to render the user interface.

Beyond this, blocks should have the ability to have a completely independent editor experience, a save function that saves semantic HTML, and a PHP rendered callback that can be used to adapt the frontend output to the ever evolving whims of clients.

Because not all blocks can have the same editor view as the frontend. Sliders are a prime example of this. Usually the workaround is to have all the editing UI in the sidebar, and use PHP rendering only, but the editing experience could be and needs to be way better than that.

Also not all the markup you need to include to achieve a desired frontend output should be in the database. It's not uncommon to add classes and IDs to HTML to be able to hook in with JavaScript. I don't see why this should be saved to the database, especially as far as data portability is concerned.

I consider that these decisions were taken because the overwhelming majority of the project team does not have any experience in working with actual client projects. That's fine, if feedback from the developers that actually use Gutenberg gets respected, and applied. But I'm also sure that as the project moves on to phase 2, where the blocks are more complex than just the very basic ones that ship with Core, the team will come to the same conclusion that everybody else creating complex blocks has.

[jamesmthornton]

Another good reason to have a skipBlockValidation method is when block validation is wrong throwing false positives:

[swissspidy]

Another good reason to have a skipBlockValidation method is when block validation is wrong throwing false positives:

Well, this shouldn't really be skipped, but fixed instead :)

[jamesmthornton]

Well, this shouldn't really be skipped, but fixed instead :)

True, but I guess my point is that we shouldn't be forcing users into features while they're creating issues. There are companies that have had to deprecate 3 generations of blocks already. It's like apple and removing the head phone jack because TinyMCE had filters to disable features. Just feels aggressive to force devs and users into a validation workflow. And the end user who doesn't know html is the one who will suffer when the whole goal of Gutenberg is to move the end user away from relying on html to use a text editor.

[maxxwv]

Also - and I have to stress this again - it puts the import on the display, not the logic or the data, which is where it should be. I work at an agency, and almost every plugin or theme I develop returns plain data as an array or object, then pipes that into custom view files. This way, when our client is ready to redesign the site, we only have to deal with the view files because the pure data is still in the database. If our client moves to another agency, that agency won't have to reinvent the wheel to redesign around the data (which I would say is just common courtesy). Not only that, if we decide to open the data to an RSS feed or API endpoint, suddenly we're serving data with proprietary markup in the stream.

[jameskhamil]

This means that if you change a single CSS CLASS NAME, you have to deprecate the entire block or the block will break and be dead to the user. ?!?!?!

Someone at Wordpress is either confused or a sadist, there's no other explanation for making developers this miserable. How many thousands of hours are going to be poured into the gutter collectively? There's not even a feature to migrate one block to the newer version?!?! There's "convert to block" and "convert to HTML", neither doing what you would expect them to do: convert to the new block, taking the attributes with.

@swissspidy: let people live "dangerous" in their controlled environments. The current mechanism is absolute insanity.

[displaynone]

If I have a block with i18n functions, when saving, it is saved in a language, but if I switch WP dashboard language the text is translated in a different language and the block is marked as not valid.

It will be a problem when several people edit same content and they have WP dashboard in different languages.

Please, keep in mind there are a lot of regions in the World were 2 languages coexists as official languages and it is common to see some people has WP dashboard in a language different than other team members.

[youknowriad]

Closing as a duplicate of #7604

We're interested in improving these flows but this is a hard problem and I haven't seen good proposals so far.