[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