[wp-trac] [WordPress Trac] #59661: WP_Query::generate_cache_key should consider changes to request via `posts_request_ids` filter.

[WordPress Trac]

#59661: WP_Query::generate_cache_key  should consider changes to request via
`posts_request_ids` filter.
--------------------------+-----------------------------
 Reporter:  thekt12       |      Owner:  thekt12
     Type:  defect (bug)  |     Status:  assigned
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Cache API     |    Version:  trunk
 Severity:  minor         |   Keywords:
  Focuses:  performance   |
--------------------------+-----------------------------
 In `WP_Query::get_posts()`, [https://github.com/WordPress/wordpress-
 develop/blob/781953641607c4d5b0743a6924af0e820fd54871/src/wp-includes
 /class-wp-query.php#L3175 $cache_key   = $this->generate_cache_key( $q,
 $new_request );] doesn't consider the possibility for changes to the
 request via [https://github.com/WordPress/wordpress-develop/blob/6.3/src
 /wp-includes/class-wp-query.php#L3310 posts_request_ids] filter.

 This can result in cache collision.

 For example we have one page doing `get_posts` with this filter,
 and we have a different page that doesn't use the filter but does the same
 `get_posts`  with exactly same args. This will result in two different
 request to have same result.

 To give overview, `posts_request_ids`filter is used to modify final
 `post_ids` in a split operation.


 Solution is to have check for `has_filter( 'posts_request_ids' )`,
 serialize outcome from global `$wp_filter[ 'posts_request_ids' ]` and set
 to to `args` before cache_key is generated. Seralization  we also allow
 for the cases where just one of he array of filters set in
 `posts_request_ids` is modified.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/59661>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform