Skip to content

Update block syncing to account for invalid blocks - #47

Closed
ingeniumed wants to merge 2 commits into
vip-rtcfrom
update/block-syncing-for-errors
Closed

Update block syncing to account for invalid blocks#47
ingeniumed wants to merge 2 commits into
vip-rtcfrom
update/block-syncing-for-errors

Conversation

@ingeniumed

Copy link
Copy Markdown

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

  • Follow the screen recording on vip-rtc, and on this branch to see the difference in behaviour.

@ingeniumed
ingeniumed requested a review from nerrad as a code owner October 16, 2025 22:21
@github-actions

Copy link
Copy Markdown

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.

  • Type-related labels to choose from: [Type] Automated Testing, [Type] Breaking Change, [Type] Bug, [Type] Build Tooling, [Type] Code Quality, [Type] Copy, [Type] Developer Documentation, [Type] Enhancement, [Type] Experimental, [Type] Feature, [Type] New API, [Type] Task, [Type] Technical Prototype, [Type] Performance, [Type] Project Management, [Type] Regression, [Type] Security, [Type] WP Core Ticket, Backport from WordPress Core, Gutenberg Plugin, New Block.
  • Labels found: .

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.

@github-actions

github-actions Bot commented Oct 16, 2025

Copy link
Copy Markdown

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 props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: ingeniumed <ingeniumed@git.wordpress.org>
Co-authored-by: chriszarate <czarate@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

@chriszarate

chriszarate commented Oct 16, 2025

Copy link
Copy Markdown
Member

Why wouldn't we prevent invalid blocks from syncing, instead of letting them sync and re-parsing blocks?

@chriszarate

Copy link
Copy Markdown
Member

@ingeniumed fyi for my question above

@ingeniumed

Copy link
Copy Markdown
Author

Why wouldn't we prevent invalid blocks from syncing, instead of letting them sync and re-parsing blocks?

(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 isValid property to hold back invalid blocks just like the gallery block.

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.

@ingeniumed

Copy link
Copy Markdown
Author

Previously, I would do the following:

  • Insert a custom server side registered static block
  • Tweak the save function to return a different markup
  • Refresh or load a new client
  • Watch the content vanish entirely as block recovery was triggered

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants