[wp-trac] [WordPress Trac] #57012: WP_Query caching discards `posts_fields` and `posts_clauses['fields']` filters.

WordPress Trac noreply at wordpress.org
Mon Nov 7 01:54:45 UTC 2022


#57012: WP_Query caching discards `posts_fields` and `posts_clauses['fields']`
filters.
---------------------------+---------------------
 Reporter:  peterwilsoncc  |       Owner:  (none)
     Type:  defect (bug)   |      Status:  new
 Priority:  normal         |   Milestone:  6.1.1
Component:  Query          |     Version:  6.1
 Severity:  normal         |  Resolution:
 Keywords:                 |     Focuses:
---------------------------+---------------------

Comment (by peterwilsoncc):

 I've created a mini-plugin to modify the fields requested by `WP_Query`:


 {{{#!php
 <?php
 add_action( 'init', function() {
         add_filter( 'posts_fields', function( $fields ) {
                 $fields .= ', 1 as test_post_fields';
                 return $fields;
         } );

         add_filter( 'posts_clauses', function( $clauses ) {
                 $clauses['fields'] .= ', 2 as test_post_clauses';
                 return $clauses;
         } );

         $query2 = new WP_Query(
                 array(
                         'post_type' => 'post',
                         'posts_per_page' => 1,
                         'fields' => 'id=>parent',
                         'cache_results' => false,
                 )
         );

         var_dump( $query2->posts );

         exit;
 }, 999 );
 }}}

 When initializing `WP_Query( 'fields' => $value )` the following happens
 in 6.0:

 * `$value = 'ids'`: The `posts` property is an array if integers. The 6.1
 behaviour matches.
 * `$value = 'all' /* or '' */`: The `posts` property contains an array of
 `WP_Post` objects with the addition of `test_post_fields` and
 `test_post_clauses`. The 6.1 behaviour does not match.
 * `$vallue = 'id=>parent'`: The `posts` property contains an array of
 `stdClass` with the properties `ID`, `post_parent`, `test_post_fields` and
 `test_post_clauses`. The 6.1 behaviour does not match.

 I see two options:

 * bypass caching if the fields are not one of the three expected values
 `WP_Query` handles by default
 * include the SQL fields in the cache key if the fields are not one of the
 three expected values

 Either way, tests will need to be added to ensure changing the fields
 includes the additional values in the event the `posts` property is an
 object.

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


More information about the wp-trac mailing list