Update block syncing to account for invalid blocks - #47
Conversation
|
Warning: Type of PR label mismatch To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.
Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task. |
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Why wouldn't we prevent invalid blocks from syncing, instead of letting them sync and re-parsing blocks? |
|
@ingeniumed fyi for my question above |
(Noting that I answered this in our internal discussion as part of discussing this PR, so I'm summarising it below) We would still need to parse the content, to get the blocks out and understand what's valid and what's not. The actual blocks are empty when the content has invalid markup, so there are no blocks to sync in the first place. The solution I first tried was this one, because I figured we could use the As a result, we would this PR in place to be able to understand what blocks are valid and what aren't. Hopefully I've clarified that properly, and happy to be corrected on this if you've found something that does allow this. |
|
Previously, I would do the following:
Then, with the addition of the above PR the block recovery page would correctly trigger across all the clients. Now, even without the above PR the block recovery page correctly triggers across all the clients. I have attempted to repeat this a few times and can confirm it's working. This was one of the main reasons why I had put up this PR as I could replicate it outside the code editor. I'm not sure if switching to the main GB repo did it, or nuking my entire setup did it but my old steps no longer work. So I'm going to go ahead and close this out and instead open up a draft PR against the RTC plugin to disable the code editor. |
Description
Currently, using invalid markup or messing up the markup via the code editor leads to content being lost. This is different behaviour than if RTC wasn't turned on where the block recovery errors would crop up.
Screen.Recording.2025-10-13.at.11.16.40.mov
The problem comes from the content being defined (albeit problematic), but the blocks being empty. So the key here is to, parse out the blocks from content, account for errors being thrown from the invalid markup, and then using that as the blocks going forward. This matches the behaviour without RTC being turned on, and avoid content being lost as well.
Testing