[wp-trac] [WordPress Trac] #64696: Real time collboration effectively disables persistent post caches while anyone edits a post

[WordPress Trac]

#64696: Real time collboration effectively disables persistent post caches while
anyone edits a post
--------------------------------------+--------------------------
 Reporter:  peterwilsoncc             |       Owner:  (none)
     Type:  defect (bug)              |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  Posts, Post Types         |     Version:  trunk
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:  performance
--------------------------------------+--------------------------

Comment (by sippis):

 Dropping a .2$ from the perspective of developer who works with big
 enterprise clients. I'll be quite frank with the comment, sorry for that.

 Let me remind you, the current post meta workaround was brought to the
 table three days ago accompanied by this introductory comment:

 Replying to [comment:83 ellatrix]:
 > I just created something quick with Claude/AI so it's only theoretical,
 I haven't tested. That's probably stuff I'm missing, I'm not very familiar
 with this side of core.

 Replying to [comment:111 peterwilsoncc]:
 > I think there are two competing factors:
 >
 > * there is broad agreement that RTC both warrants and needs a custom
 table
 > * there are concerns that the custom table needs further discussion
 >
 > If that is the case then the safest solution as the release candidate
 approaches is to drop the feature and continue development in the
 Gutenberg plugin, extending the plugin to include the custom table.

 +1 this

 I'd very much prefer a thoroughly vetted and well-discussed feature over a
 rushed, half-baked vibe coded workaround that everyone already know is
 temporary.

 It's worth to keep in mind that if non-query-cacheable post meta keys are
 introduced, people will start using that feature out in the wild. There's
 no taking it back and the possibility of removing it later on, even when
 better approach for RTC is introduced. Such a major new feature should've
 been discussed and tested way earlier in the process, on a separate
 ticket, rather than introducing it as a byproduct of a rushed fix.

 **RC1 simply isn't the right point in release work to be debating around
 such a high-steaks decision.**

 I'm sure ya'll are aware of the [https://wordpress.org/about/philosophy/
 WordPress philosophy], but let's remind ourselves about it:

 > The more frequent and regular releases are, the less important it is for
 any particular feature to be in this release. If it doesn’t make it for
 this one, it’ll just be a few months before the next one.

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