Providing a validation UI for unexpected or invalid content issue

[amitpatel0702]

What problem does this address?

Usually when a user enters any invalid tag in the Gutenberg editor, one may encounter with "This block contains unexpected or invalid content." and then it makes extremely difficult for a user to fix or resolve that issue. All option to fix the block or convert to block or classic editor breaks the tags and all the HTML part if lost.

What is your proposed solution?

Is it possible to provide a UI that immediately triggers once user enters invalid tag?
In order to accomplish this, we might need to run a code that runs in the background for every line and keeps checking if tags are closed or formatted well. This will minimize the efforts and prevent confusion that most of the users have faced to either attempt recovery, or convert block to the classic editor or HTML blocks.

[paaljoachim]

Thank you for adding this issue @amitpatel0702 Amit!

[talldan]

@amitpatel0702 I fixed some problems with the issue description, the text you added under 'What is your proposed solution' wasn't being shown.

I notice this sentence seems unfinished:

Usually when a user enters any invalid tag in the Gutenberg editor, one may encounter with "This block contains unexpected or invalid content." and then

Is there something that you were going to add?

[amitpatel0702]

Hi @talldan, Thanks for Bringing it to my attention.
Let me add the sentence once again here to provide more understanding.

Usually when a user enters any invalid tag in the Gutenberg editor, one may encounter with "This block contains unexpected or invalid content." and then it makes extremely difficult for a user to fix or resolve that issue. All option to fix the block or convert to block or classic editor breaks the tags and all the HTML part if lost.

So my suggestion was if we can add some enhancements in future release which. provides initial validation for this scenario in order to get rid of this deadlock situation.

[talldan]

Thanks - I've updated that.

[dmsnell]

it's possible to enter invalid HTML through the text/code editor in Gutenberg and to create "invalid" or unrecognizable markup. when leaving that text field with the serialized HTML the editor will show that warning because it can't make sense of the block. it's possible to go back into that text view to correct the HTML.

Some parts of your prompt are unclear to me @amitpatel0702 - where are you editing the document? Are you doing it from the code editor? where are you wanting an error to appear?

Note that the block recovery tools are still kind of in an odd spot. There is work that can/will be done to make those better, but they have their own set of issues at the moment if the block markup is invalid in certain ways, often because of manually editing the HTML.

[amitpatel0702]

Hi @dmsnell, Thanks for sharing your thoughts.

I agree with you and thought the same - That I would be able to fix the markup by choosing resolve or convert to HTML block option. But the issue I identified arised while working with List block and nesting lists. While a user clicks on resolve or convert to block, it erases entire list content instead of preserving markup.

Yes, I can understand that block recovery tools are in a kind of in odd spot. I am just trying to think of a way to provide validation or jquery based popup or alert box which will ask user either to reenter incomplete tag or markup, and also can correct incomplete markup if user chooses so.

Let me know if it is clear and makes sense.

[dmsnell]

Yes, I can understand that block recovery tools are in a kind of in odd spot. I am just trying to think of a way to provide validation or jquery based popup or alert box which will ask user either to reenter incomplete tag or markup, and also can correct incomplete markup if user chooses so.

Those list block fixes are particularly tricky, but I think they demonstrate an aspect that will make it hard not possible to fix automatically or to even know that the problem is with the HTML tag.

One thing I hope to get back to soon for 6.2 is the "invalid" block dialog. The HTML diffing is currently broken because it doesn't take into account any inner blocks and it's the same unawareness of inner blocks that causes a lot of the automatic resolution to fail.

I'm only being a stickler on this particular issue because I believe we're discussing a symptom in here of a bigger problem and the fix for that root cause should help this and all the other related issues.

At some point I thought I grouped together a number of invalid-block-related issues but now I can't find it. Maybe for now we could close and merge this into #25436? How would you feel about that?

Is it possible to provide a UI that immediately triggers once user enters invalid tag?

Just a reminder that it's not normative for authors to enter HTML tags directly. Anyone doing this is already leaving the zone of supported interactions and so there's no place we expect to have "once [they enter an] invalid tag." The editor is built on the expectation that edits are performed visually through the block UI unless someone feels confident to leave the safety of that system.

[amitpatel0702]

Yes, We can merge this into to #25436

[dmsnell]

Merged into #25436
Thanks @amitpatel0702 for raising this issue. We'll all be better off when we have fewer confusing broken blocks.

[openmindculture]

How to activate the validation UI? All I see is the aforementioned error message, but no detail about which line is invalid. Even worse, the block code validates as 100% correct in PhpStorm using every WordPress coding standards. Come on.

[dmsnell]

Come on.

@openmindculture okay I'll bite 😄

first of all sorry to hear you're having issues with block invalidation. it's an issue dear to my heart and I sympathize with any frustration you might be feeling when trying to build blocks and seeing them fail.

correct in PhpStorm using every WordPress coding standards

this is my clue that we might be conflating different issues. unfortunately the coding standards and PhpStorm's tools won't be able to guarantee that code you write works as you expect. so to lean on them is good, but doesn't speak to whether the code runs in the editor.

if, however, I infer correctly, I'm guessing you wrote some code for a block but every time you insert it it immediately invalidates? if that's the case try checking the way your save() function stores the block's contents. if you don't have a save() function the editor will re-use your edit() function.

if the block's content doesn't "round-trip" between the attributes going into save() and the output HTML then it will invalidate. one example of where this breaks down is when updating a block in response to an event but not saving that update via setAttributes, or when something is encoded on save but not decoded on load.

what might be helpful in these cases is to view the page in the Text/code view and see what HTML is being saved into your post. does it match exactly what you expected?

I might recommend reaching out for some help in other places, forums, etc… for this becasue if I'm understanding you properly, despite having a very valid question, it's unrelated to this technical issue, which appears on normally-working blocks when someone manually enters invalidating HTML from the code editor.

[openmindculture]

Thanks @dmsnell . In our case(s) there is no save() as both themes don't use custom blocks. One is a classic / hybrid theme with a few block patterns (templates) defined as PHP files in /patterns containing Gutenberg markup copied directly from block groups that worked without errors. The other, similar case, is a full-site-editing block theme where we use block template parts. The existing code works fine in the frontend, but the Gutenberg block editor displays the unhelpful message, irritating the customers if they try to edit something else via edit website -> edit template part.

Maybe I should create a custom block just for the sake of getting some more insights when using the save method.
Or would it be possible to replicate the block editor logic into plugins for PhpStorm / VSCode so that we could validate our code like I have been used to do in any other setup except for WordPress? I can search and open a feature request unless it is already on the roadmap.

[dmsnell]

@openmindculture this reminds me of a couple different issues I have seen in the past. I think in one case the template was copied and included extra ref attributes somewhere? It was something like those referred to the original document from which the customized template was built. The other case involved extra newlines but I thought that whatever caused those was resolved.

if they try to edit something else via edit website -> edit template part.

probably the issue lies here. if possible, you might examine what changes they made and see if you can narrow them down to a single change that breaks the block. if they are like many people, they might be going in and editing HTML in a way that is different than how a block renders itself. these could be seemingly benign changes like adding extra attributes to an HTML element.

that is, if they are editing the template as HTML instead of as a Gutenberg post there's that possibility of "breaking" the content, because direct manipulation like this is still mostly an affordance while being technically unsupported.

[openmindculture]

I suspect that the Gutenberg engine prefers its comment syntax in a code style that looks inconsistent to my developer's eye:

<!-- wp:something -->
<div><!-- wp:paragraph -->
<p></p><!-- /wp:paragraph -->
</div><!-- /wp:something --><!-- /wp:somethingelse -->
<somethingelse>

So there is a newline between the opening HTML comment and the actual tag, but not newline between the tag and the next HTML, and no newline between a closing HTML comment annd the following HTML tag. And maybe it doesn't like indentation either.

At least, additional new lines between wp:group groups seem to be tolerated.

And, last but not least, I finally discovered the said validation function!
Of course the save() happens when saving a post, also when an auto-save is triggered.
Then there is a console.error in dev tools, like "Block validation: Block validation failed for core/columns", with an object containing detailed sections like a "deprecated" array, and "Content generated by save` function". I still do not see the actual error though, but at least it is a step in the right direction.

Thanks again for your replies and support!

[dmsnell]

with an object containing detailed sections like a "deprecated" array

I think if you expand that object it should indicate which fields/attributes are mismatched?

Newlines shouldn't matter that much. There was an issue, apparently just solved in the past few days, which I thought was solved before, in which newlines between blocks was causing the site editor to crash, which is different than when found in the post editor. This was because the site editor removed a fallback block handler.

There was some affordance built in when originally saving content to make block markup easier to read, inserting those newlines, but for the most part they shouldn't matter or change a post. The site editor and templates work a bit differently, especially since people are editing the HTML directly as a matter of course, vs. in the post editor when that's only the exception.