Real-time collaboration: Add new REST endpoints, setting, and registered post meta

[czarate]

In Gutenberg, we have added support for real-time collaboration using CRDT documents (via the ​Yjs library). This work has suggested the following additions to WordPress:

1. A default "sync provider" based on HTTP polling that allows collaborators to share updates with each other. Previously, we relied on WebRTC connections between collaborators for this purpose, but it proved unreliable under many network conditions.
   • Our solution is designed to work on any WordPress installation.
   • HTTP polling is the transport we identified as most likely to work universally.
   • Given the isolation and lifecycle of PHP processes, updates must be stored centrally in order to be shared among peers. We have chosen to store updates in post meta against a special post type, but alternate storage mechanisms are possible.
   • Collaborative editing can involve syncing multiple CRDT documents. To limit the number of connections consumed by this provider, requests are batched.
   • To prevent unbounded linear growth, updates are periodically compacted.
   • To avoid excessive load on lower-resourced hosts, this provider will benefit from usage limits (e.g., a maximum of three connected collaborators) enforced by the client (Gutenberg).

2. A new registered post meta that allows Gutenberg to persist CRDT documents alongside posts.
   • This provides all collaborators with a "shared starting point" for the collaborative session, which avoids duplicate updates.
   • Content stored in the WordPress database always remains the source of truth. If the content differs from the persisted CRDT document, the CRDT document is updated to match the database.

3. A new Writing setting that allows users to opt-in to real-time collaboration.
   • Enabling real-time collaboration disables post lock functionality and connects users to the sync provider.

4. A behavior change to autosaves is needed. When the the original author is editing a draft post (post_status == 'draft' OR 'auto-draft') and they hold the post lock, the autosave targets the actual post instead of an autosave revision. This puts the post data and the persisted CRDT document out of sync and leads to duplicate updates. When real-time collaboration is enabled, all collaborators must autosave in the same way.

This wordpress-develop PR provides a proposed implementation of the changes above, but discussion is no doubt needed:

​https://github.com/WordPress/wordpress-develop/pull/10894

This corresponding Gutenberg PR moves the work from the experimental directory to lib/compat:

​https://github.com/WordPress/gutenberg/pull/75366

Cumulative work to add this functionality can be found using this label:

​https://github.com/WordPress/gutenberg/issues?q=label%3A%22%5BFeature%5D%20Real-time%20Collaboration%22%20is%3Apr

## Description

Trac ticket: https://core.trac.wordpress.org/ticket/64622

In Gutenberg, we have added support for real-time collaboration using CRDT documents (via the ​Yjs library). This work has suggested the following additions to WordPress:

1. A default "sync provider" based on HTTP polling that allows collaborators to share updates with each other. Previously, we relied on WebRTC connections between collaborators for this purpose, but it proved unreliable under many network conditions.
   • Our solution is designed to work on any WordPress installation.
   • HTTP polling is the transport we identified as most likely to work universally.
   • Given the isolation and lifecycle of PHP processes, updates must be stored centrally in order to be shared among peers. We have chosen to store updates in post meta against a special post type, but alternate storage mechanisms are possible.
   • Collaborative editing can involve syncing multiple CRDT documents. To limit the number of connections consumed by this provider, requests are batched.
   • To prevent unbounded linear growth, updates are periodically compacted.
   • To avoid excessive load on lower-resourced hosts, this provider will benefit from usage limits (e.g., a maximum of three connected collaborators) enforced by the client (Gutenberg).

2. A new registered post meta that allows Gutenberg to persist CRDT documents alongside posts.
   • This provides all collaborators with a "shared starting point" for the collaborative session, which avoids duplicate updates.
   • Content stored in the WordPress database always remains the source of truth. If the content differs from the persisted CRDT document, the CRDT document is updated to match the database.

3. A new Writing setting that allows users to opt-in to real-time collaboration.
   • Enabling real-time collaboration disables post lock functionality and connects users to the sync provider.

4. A behavior change to autosaves is needed. When the the original author is editing a draft post (post_status == 'draft' OR 'auto-draft') and they hold the post lock, the autosave targets the actual post instead of an autosave revision. This puts the post data and the persisted CRDT document out of sync and leads to duplicate updates. When real-time collaboration is enabled, all collaborators must autosave in the same way.

This PR provides a proposed implementation of the changes above. This corresponding Gutenberg PR moves the work from the experimental directory to lib/compat:

​https://github.com/WordPress/gutenberg/pull/75366

Cumulative work to add this functionality can be found using this label:

​https://github.com/WordPress/gutenberg/issues?q=label%3A%22%5BFeature%5D%20Real-time%20Collaboration%22%20is%3Apr

## Testing instructions

1. Check out this branch and follow the setup instructions in the README.
2. Settings > Writing > Enable real-time collaboration.
3. Open a post for editing in two browsers / browser tabs.

Is there any tests we can add for the default provider and new functionality?

Can we also provide some documentation on how to override the provider given it's known limitation listed above?

Why isn't each room a post?

No strong reason. Mostly to avoid creating a large number of posts. Each room corresponds to a synced CRDT document (representing a WordPress entity). Currently supported entity types:

• posts (any post type)
• taxonomy collections

In the future, this could be expanded to include all database entities, including individual taxonomy terms. We might also create rooms to share awareness data at the page or screen level.

We intend to enforce limits on this default provider, but probably applied to simultaneous collaborators and not on the overall number of synced entities. Sharing a single post felt prudent but happy to reconsider! I know wp_postmeta#meta_key is indexed but I don't have a grasp on the performance tradeoff at large scale.

[jorbin]

A new Writing setting that allows users to opt-in to real-time collaboration.

This seems to go against both the Out of the box and Decisions, not options ​philosophy points. Can you share some of the rationale behind this?

[czarate]

This seems to go against both the Out of the box and Decisions, not options ​philosophy points. Can you share some of the rationale behind this?

Real-time collaboration by default should be our goal. However, it's a significant change to how editing works, both for human workflows and for third-party integrations. We want to expose users to this valuable new feature while giving site administrators control in case they need time to update their processes or code.

Additionally, the default sync provider is designed to allow every WordPress installation the ability to use real-time collaboration. However, the ideal sync provider for a given installation may vary depending on its size, the number of active editors, and the capabilities of its host. Over time, we expect that hosts will implement their own sync providers, similar to how object caching works.

Given this, a top-level on/off setting seems like a useful control at this early stage of exposure—but temporary. At some point soon, we expect that the feature will be enabled by default and this control would be removed.

[jorbin]

At some point soon, we expect that the feature will be enabled by default and this control would be removed.

That point needs to happen before this is committed to core.

Also, when should we expect a merge proposal on make/core?

[youknowriad]

I think the setting for RTC is probably the safest path forward. This is a big impactful feature. A way to disable the feature seems mandatory to me (either opt-in or opt-out). There's no possibility for RTC to work without issues entirely in all WordPress installs.

[czarate]

Also, when should we expect a merge proposal on make/core?

Starting work on this and plan on having it ready to publish on Wednesday.

Fix one of the failing unit tests here: ​https://github.com/chriszarate/wordpress-develop/pull/1 since I couldn't PR against this.

Note that I've removed the commit that updates Gutenberg to the required version to allow unit tests to pass. The testing instructions have been updated accordingly.

Thanks for the update George and please help me get the best account
partnered sponsor for your operations platform. I ALSO believe that my
keys and music are in the 2B but I'm not sure if the id is on me and if
free we're my in investments.? Thanks gclapps0612 has like 20 ids and many
# that are old. I love working in thus org but. I am confused because I
was compromised according to my report. And I am a 2004 space 5g 6g cancer
prototype for research but haven't been able to get my certs and doc. To
confirm electrical variance and sound sequence, to light and sound but I
am here trying. Thanks for not giving up on me

Forgive me for not telling you that I am so much better now that I am the

element ✨️ in lights on me. Are we done and if satellite id is the key ?
Beacon light

On Tue, Feb 17, 2026, 10:48 PM github-actions[bot] *@*.*>
wrote:

*github-actions[bot]* left a comment (WordPress/wordpress-develop#10894)
<​https://github.com/WordPress/wordpress-develop/pull/10894#issuecomment-3918406241>

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.

Core Committers: Use this line as a base for the props when committing in
SVN:

Props czarate, paulkevan, timothyblynjacobs, westonruter.

*To understand the WordPress project's expectations around crediting
contributors, please review the Contributor Attribution page in the Core
Handbook
<​https://make.wordpress.org/core/handbook/best-practices/contributor-attribution-props/>.*

—
Reply to this email directly, view it on GitHub
<​https://github.com/WordPress/wordpress-develop/pull/10894#issuecomment-3918406241>,
or unsubscribe
<​https://github.com/notifications/unsubscribe-auth/BXZWJXC2PMKTI4QJG5Y6EEL4MPOI3AVCNFSM6AAAAACUSITQUGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSMJYGQYDMMRUGE>
.
You are receiving this because you are subscribed to this thread.Message
ID: *@*.*>

One of my first questions, which was already asked by @TimothyBJacobs, is related to the use of a single wp_sync_storage post.

Unless I'm misreading it, when add_post_meta, update_post_meta, and delete_post_meta are called, they invalidate all the cached meta for that post ID, but because every room shares the same wp_sync_storage post, that means all cached sync data across all rooms is invalidated. It's hard to understand why an editing session on post ID 1 should impact the caching and performance of a session on post ID 2.

In testing with 3 clients, I'm seeing thousands of post meta function calls within minutes. I think some of that could be alleviated by giving each room its own wp_sync_storage post, so that meta cache invalidation is scoped to a single session rather than all of them.

In testing with 3 clients, I'm seeing thousands of post meta function calls within minutes. I think some of that could be alleviated by giving each room its own wp_sync_storage post, so that meta cache invalidation is scoped to a single session rather than all of them.

That's great feedback, thank you. I'll explore using separate posts in a new PR based on this one.

@mindctrl, I've implemented your suggestion in ​this PR. cc @TimothyBJacobs

[ellatrix]

Let's try opt-out during the beta cycle for maximum testing. Discussed this with @matveb, @annezazu, and the contributors involved. We can leave the option present in case beta users need to disable it and so we have an easy way to flip the switch back at any point in the cycle.

[ellatrix]

In 61689:

Real-time collaboration: add new REST endpoints, setting, and registered post meta.

Syncs/merges the PHP changes from the Gutenberg PR ​https://github.com/WordPress/gutenberg/pull/75366.

In Gutenberg, we have added support for real-time collaboration using CRDT documents (via the [Yjs library](​https://yjs.dev/)). This work has suggested the following additions to WordPress:

1. A default "sync provider" based on HTTP polling that allows collaborators to share updates with each other. Previously, we relied on WebRTC connections between collaborators for this purpose, but it proved unreliable under many network conditions.
   • Our solution is designed to work on any WordPress installation.
   • HTTP polling is the transport we identified as most likely to work universally.
   • Given the isolation and lifecycle of PHP processes, updates must be stored centrally in order to be shared among peers. We have chosen to store updates in post meta against a special post type, but alternate storage mechanisms are possible.
   • Collaborative editing can involve syncing multiple CRDT documents. To limit the number of connections consumed by this provider, requests are batched.
   • To prevent unbounded linear growth, updates are periodically compacted.
   • To avoid excessive load on lower-resourced hosts, this provider will benefit from usage limits (e.g., a maximum of three connected collaborators) enforced by the client (Gutenberg).

2. A new registered post meta that allows Gutenberg to persist CRDT documents alongside posts.
   • This provides all collaborators with a "shared starting point" for the collaborative session, which avoids duplicate updates.
   • Content stored in the WordPress database always remains the source of truth. If the content differs from the persisted CRDT document, the CRDT document is updated to match the database.

3. A new Writing setting that allows users to opt-in to real-time collaboration.
   • Enabling real-time collaboration disables post lock functionality and connects users to the sync provider.

4. A behavior change to autosaves is needed. When the the original author is editing a draft post (post_status == 'draft' OR 'auto-draft') and they hold the post lock, the autosave targets the actual post instead of an autosave revision. This puts the post data and the persisted CRDT document out of sync and leads to duplicate updates. When real-time collaboration is enabled, all collaborators must autosave in the same way.

This PR provides a proposed implementation of the changes above. This corresponding Gutenberg PR moves the work from the experimental directory to lib/compat:

​https://github.com/WordPress/gutenberg/pull/75366

Cumulative work to add this functionality can be found using this label:

​https://github.com/WordPress/gutenberg/issues?q=label%3A%22%5BFeature%5D%20Real-time%20Collaboration%22%20is%3Apr

Developed ​https://github.com/WordPress/wordpress-develop/pull/10894.

Props czarate, paulkevan, ellatrix, timothyblynjacobs, westonruter, jorgefilipecosta, mindctrl.
Fixes #64622.

[ellatrix]

In 61694:

Restore ca-bundle.crt changes after r61689.

r61689 accidentally reverted the change to src/wp-includes/certificates/ca-bundle.crt from r61685, so this commit restores it using svn diff -c 61685 ^/trunk | patch -p0.

Props dd32, mukesh27, johnbillion.
See #64245. See #64622.

Increase $wp_db_version since the schema was changed in ​https://github.com/WordPress/wordpress-develop/pull/10894

Trac ticket: https://core.trac.wordpress.org/ticket/64622

The new option is set by populate_options(), which is only called during an upgrade.

[ellatrix]

In 61696:

Update db_version after r61689.

Props czarate, paulkevan, dd32.
See #64622.

Fix autosave controller tests, which began failing when RTC was changed to enabled by default. The tests now need to cover two different code paths:

​https://github.com/WordPress/wordpress-develop/blob/15ffb4392eddb43fdd9f31e075ebc85e857664c1/src/wp-includes/rest-api/endpoints/class-wp-rest-autosaves-controller.php#L259

Trac ticket: https://core.trac.wordpress.org/ticket/64622

## Use of AI Tools

Partially generated by Claude Code

[ellatrix]

In 61697:

Real-time collaboration: fix unit tests.

Fixes autosave controller tests, which began failing when RTC was enabled. The tests now need to cover two different code paths:

​https://github.com/WordPress/wordpress-develop/blob/15ffb4392eddb43fdd9f31e075ebc85e857664c1/src/wp-includes/rest-api/endpoints/class-wp-rest-autosaves-controller.php#L259

Props czarate.
See #64622.

Backport fix for "Disconnected" dialog in the site editor when real-time collaboration is enabled. See related Gutenberg fix in ​https://github.com/WordPress/gutenberg/pull/75746:

## What?

When comments are a part of the post template, the site editor will show a "Disconnected" dialog when real-time collaboration is enabled:

This can be replicated by:

1. Disable RTC via WordPress Admin -> Settings -> Writing, and uncheck the "Enable real-time collaboration" checkbox. Click the "Save Changes" button.
2. Go to WordPress Admin -> Appearance -> Editor.
3. Edit the post template to include comments and then click "Save":

​https://github.com/user-attachments/assets/e097b9b5-63f1-4b6f-b9f3-741deb718cff

4. Re-enable RTC.
5. Go back to the appearance editor and wait a bit.
6. See the "Disconnected" dialog above.

## Why?

When comments are present on the site editor page, we request entity rooms for individual comments loaded on the page, like root/comment:1, root/comment:2, etc. Due to the fact that these have specified object IDs, ​this part of the code returns false and returns a 401 to the user, triggering the dialog.

## How?

The fix here adds a special case for comments with specified IDs and does a special check against the comment. This isn't particularly robust for other special cases we may run into, but it does allow subscriptions to individual comment rooms.

[ellatrix]

After some discussion with some of the release team and people involved, we decided it's better to make it opt-in during Beta 1 to allow more time for testing and iron out kinks.

Revert the changes that enabled RTC by default for WP 7.0 Beta 1 per this comment.

• This improves and preserves the unit tests for WP_REST_Autosaves_Controller so that they pass whether the feature is enabled or not.
• Since the REST API endpoints are conditionally registered, the QUnit fixtures must be updated.

We'll need to bump $wp_db_version again once this lands.

[ellatrix]

In 61702:

Real-time collaboration: change to opt-in.

Developed in ​https://github.com/WordPress/wordpress-develop/pull/10982.

Props czarate.
Fixes #64622.

We'll need to bump $wp_db_version again once this lands.

@pkevan Do we? We already did a bump that will have caused the option to be populated. Once it's populated, a further bump will not do anything? Those who triggered the DB upgrade will have it enabled by default, but they can turn it off in settings. Those who hadn't upgraded yet will get it disabled by default? Or is this incorrect?

We'll need to bump $wp_db_version again once this lands.

@pkevan Do we? We already did a bump that will have caused the option to be populated. Once it's populated, a further bump will not do anything? Those who triggered the DB upgrade will have it enabled by default, but they can turn it off in settings. Those who hadn't upgraded yet will get it disabled by default? Or is this incorrect?

yeah I was confused - ignore me 😄

[ellatrix]

In 61704:

Real-time collaboration: fix comment syncing in site editor.

Developed in ​https://github.com/WordPress/wordpress-develop/pull/10981.
See also ​https://github.com/WordPress/gutenberg/pull/75746.

Props alecgeatches, czarate.
See #64622.

[peterwilsoncc]

Since WordPress 5.8.0, all new options have been prefixed with wp_ in the spirit of prefixing all the things to avoid the potential for conflict.

It would be good to rename the option from enable_real_time_collaboration to wp_enable_real_time_collaboration to continue this practice.

PR incoming.

Renames the option enable_real_time_collaboration to wp_enable_real_time_collaboration to follow convention since WordPress 5.8 to prefix new core options with wp.

Trac ticket: https://core.trac.wordpress.org/ticket/64622#comment:34

## Use of AI Tools

Nil.

Noting only that changing the option name will turn off real-time collaboration for anyone who has turned it on previously using the beta 1 release. (I think this is fine.)

Yeah, I'm fine with that too as it hasn't been in a production version.

For the associated Gutenberg PR, I've included a migration because the feature has been active in the plugin for a little longer. ​https://github.com/WordPress/gutenberg/pull/75837

[peterwilsoncc]

In 61722:

Editor: Add wp_ prefix real time collaboration option.

Renames the option enable_real_time_collaboration to wp_enable_real_time_collaboration to include the prefix as has been the practice for new options since WordPress 5.8.0.

Props peterwilsoncc, mukesh27, parthvataliya, czarate.
See #64622.

Merged r61722 / ​https://github.com/WordPress/wordpress-develop/commit/155e301fcd88e41f34f78a74f988674c02605b2d

Backport of PHP changes from ​https://github.com/WordPress/gutenberg/pull/75883. Changes the real-time collaboration polling server endpoint to accept null for awareness values, which is used to explicitly disconnect users leaving the page and remove their awareness data more quickly.

Trac ticket: https://core.trac.wordpress.org/ticket/64622

## Use of AI Tools

Claude for the original PR.

[ellatrix]

In 61746:

Real-time collaboration: Remove ghost awareness state explicitly when refreshing.

Syncs PHP changes from ​https://github.com/WordPress/gutenberg/pull/75883. Changes the real-time collaboration polling server endpoint to accept null for awareness values, which is used to explicitly disconnect users leaving the page and remove their awareness data more quickly.

CI run: ​https://github.com/WordPress/wordpress-develop/pull/11049.

Fixes #64622.
Props alecgeatches.

Backport for awareness timeout update from Gutenberg PR - ​https://github.com/WordPress/gutenberg/pull/76065

Trac: https://core.trac.wordpress.org/ticket/64622

The 30 s awareness timeout matched the background-tab polling interval exactly, causing awareness entries to expire between polls and triggering false "X has left" notifications that resolved on the next poll cycle.

Increase to 70 s to comfortably exceed the polling interval. The value accounts for Chrome's intensive throttling which can delay background tab timers to ~60 s

This is no longer required. We went with adjusting the polling interval when tab is in background which does not require backport PR - ​https://github.com/WordPress/gutenberg/pull/76065/changes/9daebb68bac8682b84ad9db09b4885e7f398a1e7

[audrasjb]

This is worth mentioning in the Field Guide.
Also adding needs-dev-note just in case we can mention it in a more general note.

[ellatrix]

We're reopening this ticket because we want to try enabling it by default for Beta 3.

Trac ticket: https://core.trac.wordpress.org/ticket/64622

Enable RTC by default (opt-out). This reverses a previous decision for WP 7.0 Beta 1 to keep it opt-in. Note that any installation previously running a WP 7.0 beta will continue to have RTC disabled unless the database is re-initialized.

[ellatrix]

In 61828:

Real-time collaboration: enable by default.

The option name is changed since the previous option name set a default value during database initialization. A default is no longer needed since the default is false.

Developed in: ​https://github.com/WordPress/wordpress-develop/pull/11159.

Fixes #64622.
Props czarate.

[peterwilsoncc]

I'm of the view that negative option names are a bad idea as they add cognitive load for developers. Code needs to be written as if ( ! $thing ) then { enable() } whereas if ( $thing ) { enable() } is significantly easier to parse while reading or writing code.

The default option schema also includes options that are falsey by default, eg allowing registration of users, the use of pages for the blog listing, privacy page IDs, etc. I think it best to continue previous practices.

I'd like to revert r61828 and simply change the option default value if that's the desired change.

[SergeyBiryukov]

Replying to peterwilsoncc:

I'd like to revert r61828 and simply change the option default value if that's the desired change.

I tend to agree with this reasoning.

[czarate]

I'd like to revert r61828 and simply change the option default value if that's the desired change.

The desired change is a bit more complex:

Enable RTC by default for everyone:

1. Even those that may have previously visited Settings > Writing and clicked save (for any reason).
2. Even on hosts that do not run upgrade routines. (​https://wordpress.slack.com/archives/C18723MQ8/p1771506588384619)

Point 1 requires that we change the option name or write a migration.

Point 2 strongly suggests that we remove the option from schema.php so that we don't run into this trouble again (if we decide to switch back to opt-out for final release). Instead we can rely on passing a default value to get_option.

I agree with the cognitive overload of default-negative options.

Enable Real Time Collaboration by default.

Trac ticket: https://core.trac.wordpress.org/ticket/64622

• Reverts option name change
• Adds filter so default value of the option is true.

## Use of AI Tools

None.

[peterwilsoncc]

I've created ​PR#11161:

• Reverts the commit above
• Sets the default option value in populate_options to enable the feature
• Adds a default filter to default_option_wp_enable_real_time_collaboration to enable the feature without requiring the upgrade routine to run.

@czarate The PR covers item two with the default filter. Item one isn't a concern as it's a new feature so it's not possible for users of production software to have the RTC option set to zero.

My weakly held preference for upgraded sites is to only enable the feature by default for multi author blogs as there is less benefit for such sites to have RTC enabled.

[czarate]

Thanks for working on this.

Item one isn't a concern as it's a new feature so it's not possible for users of production software to have the RTC option set to zero.

If our goal is wider testing, it's unfortunate that users of previous WP 7.0 beta releases may continue to have the RTC option set to zero.

@chriszarate Actually ready for review now... I'd missed that the filter in the tests preflighting the option to off needed to use __return_zero for it to actually work due to this code:

​https://github.com/WordPress/wordpress-develop/blob/a9fbc1bf7d98d517b3f537b8e565fa31277430a4/src/wp-includes/option.php#L152-L154

[peterwilsoncc]

In 61833:

Real-time collaboration: Rename option for positive intent.

This reverts the real time collaboration option name back to wp_enable_real_time_collaboration to avoid the need to turn on a checkbox in order to turn off the feature. This is to reduce the cognitive load on both users and developers of an on is off paradigm.

To ensure Real Time Collaboration is enabled prior to the upgrade routine running on multi-site installs, the option default is filtered on the default_option_wp_enable_real_time_collaboration hook to enable the option by default.

Developed in: ​https://github.com/WordPress/wordpress-develop/pull/11161
Follow up to r61828.

Props peterwilsoncc, czarate, sergeybiryukov.
Fixes #64622.

Backport ​https://github.com/WordPress/gutenberg/pull/76223.

Disable real-time collaboration on the site editor. In performance tests, editing large documents in the site-editor suite (loading large-post.html) can cause performance tests in the site editor to time out with memory errors. This eventually times out the entire performance testing suite in CI, blocking Gutenberg PRs from merging.

Until the root issue is resolved, temporarily disable RTC on the site editor to allow performance tests to pass until we resolve the root cause.

We may not need this PR, or the original Gutenberg PR if alternate fix ​https://github.com/WordPress/gutenberg/pull/76224 is successful.

[ellatrix]

I disagree. People who already have the beta install will now NOT have RTC on by default, so we lose a lot of testing. I don't get your concern at all. Why are we optimizing for avoiding a negation? Additionally you're now requiring an upgrade to run whereas before we didn't. So you're also optimizing for avoiding a negation rather than optimizing for avoiding the user having to run an upgrade and additional testing?

Also @dd32 suggested using the second parameter of get_option to set the default rather than an upgrade. ​https://wordpress.slack.com/archives/C18723MQ8/p1772646049016559?thread_ts=1771506588.384619&cid=C18723MQ8

[desrosj]

In 61864:

Editor: Bump the database version to 61833.

The option to enable real-time collaboration was first added in [61689] as enable_real_time_collaboration with a value of 1 and the $db_version was bumped in [61696].

The option then went through a series of changes. This included: the default value changing to 0 in [61702], being renamed to wp_enable_real_time_collaboration in [61722], removed entirely in [61828], and finally being re-added as wp_enable_real_time_collaboration in [61862].

Because the $db_version was not bumped after these changes, it’s possible that the wp_enable_real_time_collaboration option is not present on any site that ran the nightly build generated between [61696] and [61702], or a nightly build/beta release published after [61828]. Since populate_options() runs when a new site is installed, this issue only affects pre-existing sites that had upgradd their database when wp_enable_real_time_collaboration was not specified as a default option within $defaults.

This bumps the database version to 61833, which is the most recent changeset to have modified the $defaults array in populate_options().

Props dlh, maxschmeling, smithjw1, kbat82.
See #64824, #64622.

[desrosj]

Reopening this for tracking purposes because it seems like there are still some questions/disagreements, so I'm unclear as to whether this is actually completed/fixed.

[61864] fixed an edge case where the editor became unusable when the wp_enable_real_time_collaboration option was missing from the database. However, if the option goes missing for some other reason, then that edge case still occurs. There is some further discussion on the other ticket, so I'll leave that on #64824.

@mukeshpanchal27 @ellatrix Thank you for the feedback, I've updated this PR accordingly.

Backport ​https://github.com/WordPress/gutenberg/pull/76322.

When RTC is enabled, the post list should not show an exclusive lock icon or user-specific lock text since multiple users can collaboratively edit the same post.

[ellatrix]

In 61986:

Real-time collaboration: disable for site editor.

In performance tests, editing large documents in the site-editor suite (loading large-post.html) can cause performance tests in the site editor to time out with memory errors.

Developed in: ​https://github.com/WordPress/wordpress-develop/pull/11181.

Props alecgeatches, mukesh27.
See #64622.

I tried testing it locally and I can still see the post lock modal.
Followed this instructions to run it locally -

npm install
npm run build:dev
npm run env:start
npm run env:install

I tried testing it locally and I can still see the post lock modal. Followed this instructions to run it locally -

npm install
npm run build:dev
npm run env:start
npm run env:install

Updating the branch fixed it. It was related to change in option name in #11289

Looks good to me, approved 🚢

@mcsf do you mind giving the updates in ​https://github.com/WordPress/wordpress-develop/pull/11234/commits/fb00824dd7f75df7a036018c23368b30f0632ede a look? I haven't added translators notes / context in Core before, so maybe not the right style or something. Let me know.

@mcsf do you mind giving the updates in ​fb00824 a look? I haven't added translators notes / context in Core before, so maybe not the right style or something. Let me know.

Thanks, @maxschmeling, I've commented on one thing, but everything else looks good

[ellatrix]

In 62074:

Real-time collaboration: Remove post list lock icon and replace user-specific lock text when RTC is enabled.

When RTC is enabled, the post list should not show an exclusive lock icon or user-specific lock text since multiple users can collaboratively edit the same post.

Merges a fix from Gutenberg: ​https://github.com/WordPress/gutenberg/pull/76322.

Developed in: ​https://github.com/WordPress/wordpress-develop/pull/11234.

See #64622.
Props maxschmeling, czarate, mcsf, shekharnwagh.

This is committed

When RTC is enabled, the "Join" action link on the post list gets stuck after the post lock expires. The heartbeat correctly clears the lock status text and CSS class, but the link text was rendered server-side at page load and never updated back to "Edit".

Root cause: PR #11234 conditionally rendered "Join" or "Edit" based on wp_check_post_lock() at page load. The heartbeat JS updates the lock class and status text but has no code to swap the action link.

Fix: Always render both "Edit" and "Join" as separate <span> elements and toggle visibility via CSS using the .wp-collaborative-editing class the heartbeat already manages. Also replaces aria-label with screen-reader-text spans so the accessible name stays in sync with the visible text across lock state changes.

Trac ticket: https://core.trac.wordpress.org/ticket/64622

## Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 4.6
Used for: Investigating the heartbeat/lock mechanism, identifying the root cause, and implementing the fix. All changes were reviewed by me.

[mcsf]

In 62146:

Real-time collaboration: Update "Join" action label in post list if lock expires

When RTC is enabled, let the "Join" action link in the post list turn into "Edit" after the post lock expires. Do this by rendering both "Edit" and "Join" as separate spans and toggling visibility via CSS using the wp-collaborative-editing class that heartbeat already manages. Do the same to aria-label with screen-reader-text spans so the accessible name stays in sync with the visible text across lock state changes.

Developed in ​https://github.com/WordPress/wordpress-develop/pull/11346.

Follow-up to [62074].

Props shekharnwagh.
See #64622.

Committed: https://core.trac.wordpress.org/changeset/62146