[wp-trac] [WordPress Trac] #40903: Filtered posts_request query can break found_posts query

WordPress Trac noreply at wordpress.org
Thu Jun 1 16:54:47 UTC 2017

#40903: Filtered posts_request query can break found_posts query
 Reporter:  andy          |      Owner:
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Query         |    Version:  trunk
 Severity:  normal        |   Keywords:
  Focuses:                |
 Suppose the `posts_request` query is built with `SQL_CALC_FOUND_ROWS`. The
 stage is set for `WP_Query::set_found_posts` issue `SELECT FOUND_ROWS()`
 because `$limits` is non-empty.

 Now suppose a plugin filters `posts_requests` to the empty string because
 it gets results another way. WP_Query will still go ahead and issue
 `SELECT FOUND_ROWS()` erroneously.

 Some plugins avoid this by filtering `found_posts_query` to the empty
 string. However, it seems like there is a better way to write the logic of
 `set_found_posts` so that it respects the filtered `posts_request` query
 and avoids the problematic statement: simply check the filtered query for
 `SQL_CALC_FOUND_ROWS` instead of looking at `$limits`.

 Proposed fix:

         private function set_found_posts( $q, $limits ) {
                 global $wpdb;
                 // Bail if posts is an empty array. Continue if posts is
 an empty string,
                 // null, or false to accommodate caching plugins that fill
 posts later.
                 if ( $q['no_found_rows'] || ( is_array( $this->posts ) &&
 ! $this->posts ) )

 -               if ( ! empty( $limits ) ) {
 +               if ( substr( $this->request, 0, 26 ) === 'SELECT
                          * Filters the query to run for retrieving the
 found posts.

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

More information about the wp-trac mailing list