Skip to content

Conversation

@ingeniumed
Copy link

Description

The idea behind this PR is to improve the block support during the sync process between n clients. To start this, blocks are filtered out before they can be worked on to ensure unsupported blocks aren't synced.

The first case is the Gallery block. The images in a gallery are first uploaded as blobs, and then uploaded to WordPress. By filtering the block out until the upload process is done, it ensures that the block isn't in a broken state on any other client also working on the post. Once the upload process is done, the block's sync goes through and it appears correctly on all the clients working on the post.

I've kept this in draft state as I'd like to ensure this is a robust solution and that there aren't any other problems I haven't foreseen.

@ingeniumed ingeniumed self-assigned this Aug 21, 2025
// Verify that the gallery block is ready to be synced.
// This means that, all images have had their blobs converted to full URLs.
// Checking for only the blobs ensures that blocks that have just been inserted work as well.
if ( 'core/gallery' === block.name ) {
Copy link
Author

@ingeniumed ingeniumed Aug 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I switched this from a switch case into an if statement just to keep it clean

@ingeniumed ingeniumed changed the title Improve block support Improve support for the gallery block Aug 25, 2025

// Except the gallery block, all the other core blocks should be synced.
// We don't want anyone to override that, as that'll cause problems.
if ( block.name.startsWith( 'core/' ) ) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ingeniumed For non-core blocks, what happens when shouldBlockBeSynced() is false? Does only 1 user get the block?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea would be that, none of the ydocs would have the block including the user who made the edit in Gutenberg. The block is considered to be "not ready to be synced" so it would be held off from being sent to all the ydocs. Presumably, whoever is using this filter would use it similar to the gallery block where after a certain condition is met it would be flipped to true and allowed to sync.

There'd def be a weird flicker where the block appears, vanishes as it's made "ready" and then shows up once its ready. But, it's better than the way the gallery block works now where you need to refresh the page.

All that said, I figured this would allow us to provide support for plugins that are out of our control or plugins like our own - RDB in their own way outside of gutenberg.

@ingeniumed ingeniumed marked this pull request as ready for review August 25, 2025 23:42
@ingeniumed ingeniumed requested a review from nerrad as a code owner August 25, 2025 23:42
@github-actions
Copy link

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.

1 similar comment
@github-actions
Copy link

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
Copy link

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 <[email protected]>
Co-authored-by: alecgeatches <[email protected]>

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

@ingeniumed
Copy link
Author

Noting as per our discussion that this will only target the gallery block.

@ingeniumed ingeniumed merged commit f2dd14f into add/experimental-collaborative-editing Aug 25, 2025
51 of 74 checks passed
@ingeniumed ingeniumed deleted the improve/block-support branch August 25, 2025 23:43
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.

3 participants