Real time collaboration should be off by default or at the very least it should be much more limited

[sc0ttkclark]

I would like to make the case that Real time collaboration should be off by default due to the impacts of the least common denominator solution that the HTTP polling has across hosting environments.

As a feature, it hasn't totally been proven yet that everyone will use it or that the vast majority of people using the editor intend to have multiple authors.

@robey ​made an extremely good point and references this ​Philosophy page quote:

The rule of thumb is that the core should provide features that 80% or more of end users will actually appreciate and use. If the next version of WordPress comes with a feature that the majority of users immediately want to turn off, or think they’ll never use, then we’ve blown it. If we stick to the 80% principle then this should never happen.

Right now in the 7.0 beta releases, the default is on for everyone. That includes:

• Every new WordPress site
• Every upgraded WordPress site
• Every site that has only one user
• Every site that has only one contributor+ user
• Every site that does not typically have multiple authors logged in at the same time
• Every site that is ! is_multi_author() (sites with no posts by more than one author total) -- note that function probably could use a $post_type argument to make this more contextually aware based on the post being edited in this case

Surely we need to reign this in because the amount of requests (1 every second for one user, every 250ms for each user if multiple people have it open) is wasteful for most sites since WordPress is used by a huge amount of sites on the web.

This feature could contribute an outsized impact on global energy / network traffic / server logs / DB resources / site resources on every site it runs on.

Part of this puzzle could be solved by a better alternative polling provider in core that's not just HTTP like Websockets but I've seen so many slow sites with tons of data / plugins and this feature absolutely scares me to my core.

It's a fantastic feature for sure but shipping this defaulted on in all of these cases would unfortunately be irresponsible.

[sc0ttkclark]

Related to some of the performance concerns: #64696

[butterflymedia]

This should definitely be off by default. I have never heard of any client of mine, my agency's clients or my friends' clients wanting this feature.

Please disable it, or, even better, remove it completely.

[jazzs3quence]

Agree with @sc0ttkclark, especially with the increase in API hits that results from RTC. The feature does not benefit all of WordPress' users in all instances, particularly in single-admin contexts.

[maxschmeling]

This is not to say that the benefit is worth the cost for everyone, but there is a small benefit to even single admin installations where you can have the same post open in different tabs, browsers, or computers as the same user and they stay in sync.

I think in the future there will be more of WordPress that relies on a real time communication, but for now it's definitely not unreasonable to say it should be disabled by default.

If we do disable by default, I would want the default lock modal to be updated to inform the user about the feature so they know they (or an admin) can turn it on if they want.

[westonruter]

See related suggestion where RTC could be disabled by default if the polling transport is being used and a persistent object cache is not available.

[peterwilsoncc]

Thank you to the representatives of various hosting companies for sharing your concerns.

To avoid burying the lede: With the number of HTTP requests and database writes required for the default set up, I agree that it's best to turn RTC off by default regardless of the site configuration.

On a fresh install with no collaborators, just opening Hello World in my browser resulted in 60 requests a minute totaling 110-120K. It's a lot of traffic for a feature that has limited use for a single author install.

For sites with two collaborators in a post, based on the numbers above the server will receive 480 HTTP requests totaling about 900K per minute. For five or ten buck hosting that's a lot of traffic.

When RTC was enabled by default, the honest truth is that I added a plugin to my personal site to ​disable RTC during the upgrade process. For a single author blog, my site is wildly over engineered and could handle the traffic, but I didn't want to increase the load on my server without due consideration at a later date.

[davidbaumwald]

I agree with others above, including fellow committer @peterwilsoncc. I've been following this and #64696 closely. RTC should be opt-in.

Personally, I think this feature still needs more "soak time" in the ecosystem before being enabled by default in Core, though it appears the direction for 7.0 has largely been decided by leadership.

That said, I appreciate the work contributors have put into building this and the effort to try to delivery this in 7.0 as a headline feature.

I do like the idea of providing a path to enable the feature through the post lock modal. That’s a user flow where someone has already hit an impasse and is presented with an alternative, allowing them to consciously opt into RTC.

[czarate]

Replying to peterwilsoncc:

On a fresh install with no collaborators, just opening Hello World in my browser resulted in 60 requests a minute totaling 110-120K. It's a lot of traffic for a feature that has limited use for a single author install.

For sites with two collaborators in a post, based on the numbers above the server will receive 480 HTTP requests totaling about 900K per minute. For five or ten buck hosting that's a lot of traffic.

Are there traffic statistics that would be acceptable? The timing constants are easily changed (and could be filterable). (And are there better statistics than traffic, perhaps total response time or CPU?)

That said, and separate from our decision for 7.0, turning the feature off by default for single-user sites makes a lot of sense to me. Exploring "fallback" entrypoints (e.g., via the post lock modal) makes this a graceful degradation.

[sippis]

Coming from an agency world where we have a lot of big enterprise clients, I do see the value of RTC. It's a feature that some clients have been asking for a quite a time already.

That being said, I don't feel confident enough to have RTC enabled for them just yet. Some will surely want it, and for them I could knowingly enable it.

Controlled rollout is definitely the way, as there's still too much of uncertainity and moving parts close to RC1 of 7.0. For example #64696 being unsolved and potential introduction of a new database table.

Replying to czarate:

Are there traffic statistics that would be acceptable? The timing constants are easily changed (and could be filterable). (And are there better statistics than traffic, perhaps total response time or CPU?)

Having things hookable is something I consider WordPress Core standard, so this should be filterable unless there's some obvious downsides or possible side-effects of it.

[Kenshino]

Besides the performance impact to the sites that the rest have mentioned, making calls for sites that would almost never require collaboration at the rates that @peterwilsoncc has discovered seems wasteful on an ecological basis.

On the finance side, this would likely surprise many site owners who are hosted with companies that runs plans with page view / API limits.

[peterwilsoncc]

I've converted this to a task, I think there are two actions to come out of this ticket:

Filterable polling rates: regardless of the default, this is required. These need to be JavaScript filters set in the polling client. @maxschmeling has ​opened an issue, #76499, on the Gutenberg issue tracker. Thanks Max!

For WordPress-Develop a PR will be need to modify the default to off. This will require the following changes:

• set the default to zero in populate_options()
• remove the filter in default-filters.php
• set the default value registering the setting in options.php
• Run the phpunit tests to update tests/qunit/fixtures/wp-api-generated.js

---

Edit: I totally mis-read Max's ticket on the weekend. I've created ​GB#76517 and linked a pull request to add filters to the client.

Per the conversation in Core Slack, we are moving the real-time collaboration feature to opt-in / off-by-default for 7.0 RC 1. Thank you to everyone who provided feedback during the testing period.

Note that we are intentionally changing the option name so that it will be off-by-default for everyone, including those that installed a beta release where the feature was on-by-default.

Per the conversation in Core Slack

Can you link to this conversation?

Can you link to this conversation?

Apologies, description has been updated.

[czarate]

Here is the comment posted in Core Slack about the decision to make RTC off-by-default for RC1:
​https://wordpress.slack.com/archives/C07NVJ51X6K/p1773850504196589

I don't love all the churn from renaming the option especially with RC1 less than 24 hours away.

I think the diff looks a little higher churn than it is for two reasons:

1. The alignment CS rule blows up the schema changes with whitespace changes
2. The endpoint is removed from the rest api generated file.

Without those changes the PR is about +30,-20

I'm happy with this, @chriszarate are you happy with the changes I pushed?

Yes, they look fine. Thank you. I agree with @aaronjorbin that the (bool) coercion is unnecessary, but also not harmful.

Thank you. I'm going to commit this.

[ellatrix]

In 62058:

Real-time collaboration: change to opt-in (off-by-default).

See: ​https://wordpress.slack.com/archives/C07NVJ51X6K/p1773850504196589.

We are intentionally changing the option name so that it will be off-by-default for everyone, including those that installed a beta release where the feature was on-by-default.

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

Fixes #64845.
Props czarate, peterwilsoncc, jorbin.