Looking at the test cases:

Level 2: Reconstructed
Test cases:

• Dynamic block rendering server-side content differently
• Template blocks with variable output
• Blocks with computed/derived innerHTML from attributes

and

Level 4: Invalid

• Block with incompatible save output

What do these mean?

From the HTML test example, all blocks should be silently reconstructed, except for the level 5 case, which should error out in the UI.

The goal is to 1) silently reconstruct without saving, then 2) saving the reconstruction if the user modified anything. Correct?

Level 3: RawTransformedBlock
Definition: Raw handling functions applied; block type name preserved
When: Freeform or unregistered type handlers process the content
Action: Raw HTML transformation applied
Test Cases:
Unregistered block type converted to freeform
Classic block with raw HTML content
HTML block with freeform content

Not very clear to me how much this is supposed to change from what already happens. Reading "raw handling functions applied" makes me think that we can be more confident in transforming non-block content into blocks, instead of always carefully isolating them as Freeform, but the rest of the text suggests maintaining the isolation approach.

I think this is a good start, but it would help me if we could discuss how we see this making a difference for users, what kind of new interactions they would see, and what — if any — contingencies we should plan. For example, and without endorsing of these ideas:

• If we want to perform silent transformations more often, do we need to change the granularity of post revisions, in case users want to better understand what the system did?
• Similarly, can we improve the undo/redo system to have some awareness of these transformations? Or, on the contrary, do we solidify the idea that these are meant to be invisible (under the condition that they be robust, of course)?
• Scenarios like a <!-- wp:heading surrounding both a H2 and a P tag and discarding the P (suggested somewhere above) give me pause, hence the questions above.

There was also an example of a block that should be regenerated whose tag didn't match the save output. For example, a Heading block with a single P tag. The premise is that, if we can parse the attributes, we can regenerate the whole thing. Well, but how do we parse the content attribute, since it's meant to be sourced using a selector that won't match?

We can give this a try.

I left some potential flow/code enhancements but nothing really major.

May WordPress never corrupt or lose user content! Thanks for working on this.

As I read through this patch and reflect on the original discussion, I hear a mixture of issues that now seems to branch out beyond where it was before:

• Improve our ability to auto-detect benign changes or corruption and fix them reliability when the content in a post appears as a block but is different than the editor expects.
• Gracefully auto-update blocks lacking a proper migration/deprecation from older versions of the markup.
• Smush LLM-generated block content into valid markup when it’s not.

And I think it’s hard to see this proposal as solving all of them at once because I think the needs and characteristics are different. For content which has been manually adjusted or is out of date, or which a plugin might have altered, we expect small and intentional changes within the existing structure. For LLM-generated content we expect random and self-contradictory content which looks like blocks, and importantly, without the same sense of intention behind the content. Or, perhaps more tersely: intentional edits vs. new pluasible block content.

For automation purposes, I don’t fully understand the need for the validation levels, and to some extent have always struggled understanding their role. If we attempt to rewrite blocks automatically, as is already done when loading a post, then it seems like we could add just a few more steps and wouldn’t need the classification system.

In fact, I believe that Gutenberg already handles levels 0–2, meaning only level 4 is “new” and since it requires an opt-in, requires no apparent classification scheme to introduce as a new thing. We could quietly add the flag on block registration and handle these through the existing loader.

One of the changes I’ve found most valuable from my own work is the combination of #38794, #38923, and #39523 where we started preserving so-called “invalid” content (so-called, because usually it’s valid but the editor is unaware). Before then, it was common and easy for the editor to erase content in a way similar to how this change can wipe out content from something like a Heading block which uses the DIV or SPAN element as a wrapper instead of H1–H6.

Being able to preserve content that the editor doesn’t understand seems fundamental to providing the reliability people need for trusting the editor with their content. A common flow where this is normal is when copying and pasting a post from one WordPress to another, where one lacks the appropriate plugin or version to run every block. “Invalid blocks” should stay invalid and verbatim so that they work properly when copied back to the original site.

To that end I wonder if we have seen the project evolve more towards needing a new idiom: “fix slop” with a better name. In this case, that could be the addition of a new function such as fuzzyParseBlock( blockNode, fullBlockHTML ) which can be called in flows where structure is a guess (e.g. from LLM contexts), but also which could be called as a response to a user clicking on “Attempt to fix this broken block.”

Given the liberty taken in the resolutions here, and the risk of corrupting or losing content, and the combinatorial explosion of ways to try and detect invalid markup, I think it would be wise to hesitate to add this additional transformation to the loading stage.

If an LLM workflow wants to dump something into the editor it could call fuzzyParseBlocks() separately and then dump the output of that function into the editor, meaning this can all be separate, external, tested in isolation, and exchangeable.

In some of the earlier discussions (though apparently not in #21703) I advocated for the idea of allowing blocks to register their own attribute parser to determine validity in custom ways. That still offers merit that an automated system can’t, and I think it would fit in nice with a fuzzy-parse stage. For example, a Heading block could register a fuzzy parser and do any number of things, such as grabbing the first element, or taking the plaintext content of the entire provided HTML as the heading text, or that but including formatting elements, etc… We originally had in mind benign changes like added styles, classes, and attributes, something that has been incorporated in various ways over time in the core system. Having a fuzzy system as a separate action for cases where resolution isn’t obvious seems like an appropriate match to the qualitatively distinct operation of trying to make sense out of content that is self-contradictory.

@artpi we have tools to read and write block HTML structure on the server. let’s talk if you are having issues with this.

@mtias I see a few type changes that are only visible inline where they are read. this means that unless someone knows where to look for them they won’t likely be able to find them. it would be awesome if we could add documentation in the places people will look.

• __wasMigrated and validationLevel could be added to the WPBlock type with an inline description of what it represents, even as an optional property.
• allowsReconstruction could be added to the docblock on registerBlockType() and also the WPBlockType. we have example block.json files we could extend showing its use.

In summary, if our goal is more along the lines of cleaning up LLM slop then it seems like this could be handled on its own outside of the primary loading and validation framework and cause less risk to inadvertently erasing intentional content. Maybe a lot of the mechanisms here could be moved over into a new function for that purpose.

That would give users more freedom: to click on a block and have the editor attempt lossy reconstruction, to click “Attempt cleanup” or “Paste exactly” on a paste handler if non-valid block content is detected, and to be called manually in AI flows before inserting via createBlock() or whatever.