[wp-trac] [WordPress Trac] #57163: Don't use _prime_post_caches() if meta/terms cache should be updated
WordPress Trac
noreply at wordpress.org
Mon Nov 21 11:40:34 UTC 2022
#57163: Don't use _prime_post_caches() if meta/terms cache should be updated
--------------------------+-------------------------
Reporter: ocean90 | Owner: (none)
Type: defect (bug) | Status: new
Priority: normal | Milestone: 6.1.2
Component: Query | Version: 6.1
Severity: normal | Keywords: needs-patch
Focuses: performance |
--------------------------+-------------------------
`_prime_post_caches()` tries to be smart about whether posts cache needs
to be updated by first checking if IDs aren't already cached.
Unfortunately this becomes an issue if the post itself is already cached
but not the meta/terms. In this case `_get_non_cached_ids()` returns an
empty array and thus `update_post_caches()` isn't called any longer.
I notices this first by looking into `update_post_thumbnail_cache()` since
it wasn't working as expected.
* It calls `get_post_thumbnail_id()` which calls `get_post()` and thus
primes the cache in the `posts` group
* Because of that `_prime_post_caches()` basically does nothing anymore
since the post is already cached
* Result: No meta cache is primed
But then I also found another case which was due to the changes in [54352]
for 6.1. `update_post_caches()` was replaced with `_prime_post_caches()`
causing the same issue as mentioned above. If a post is already cached but
meta/terms not, the cache won't be updated. So this part is actually a
regression in 6.1.
I'm not sure if we can update `_prime_post_caches()` to also check if
meta/terms caches are already set or if should just continue using
`update_post_caches()`.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/57163>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list