[wp-trac] [WordPress Trac] #64845: Real time collaboration should be off by default or at the very least it should be much more limited
WordPress Trac
noreply at wordpress.org
Wed Mar 11 22:30:01 UTC 2026
#64845: Real time collaboration should be off by default or at the very least it
should be much more limited
-------------------------+-------------------------------------------------
Reporter: sc0ttkclark | Owner: (none)
Type: defect | Status: new
(bug) |
Priority: normal | Milestone: 7.0
Component: Posts, Post | Version: trunk
Types |
Severity: normal | Resolution:
Keywords: | Focuses: administration, performance,
| sustainability
-------------------------+-------------------------------------------------
Description changed by sc0ttkclark:
Old description:
> 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 [[https://make.wordpress.org/core/2023/07/03/real-time-
> collaboration/#comment-45186|made an extremely good point]] and
> references this [[https://wordpress.org/about/philosophy/|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()` (no sites with posts by more
> than one author) -- 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) 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 surely be irresponsible.
New description:
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 [[https://make.wordpress.org/core/2023/07/03/real-time-
collaboration/#comment-45186|made an extremely good point]] and references
this [[https://wordpress.org/about/philosophy/|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) 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 surely be irresponsible.
--
--
Ticket URL: <https://core.trac.wordpress.org/ticket/64845#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list