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

WordPress Trac noreply at wordpress.org
Mon Mar 16 15:04:40 UTC 2026


#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 joehoyle):

 Replying to [comment:64 ellatrix]:
 > A dumb question: why can't we allow registering post meta keys that are
 not queryable (through `WP_Query` etc.) and then don't invalidate cache?
 For these keys it would only be possible to retrieve the values directly
 through `get_post_meta`. This doesn't have to be a one-off special-case
 hack but rather a built-in way to do it.
 >
 > I'm bit concerned with adding a table this late in the release cycle.
 RC1 is Thursday, so this would have to be added before then. Correct me if
 I'm wrong, but we're also setting something in stone now that becomes hard
 to change or undo later.

 I've seen many cases where essentially a "non-autoloaded" post meta
 registration would be valuable, which could have different semantics for
 the last_changed date. Perhaps there is many good reasons to have custom
 tables for the collaborative data types, but if this is primarily about
 caches on post objects, it seems like a way to circumvent that problem
 directly could be good.

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


More information about the wp-trac mailing list