[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