[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 23:15:51 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()` (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.

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 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.

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64845#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list