Opened 7 years ago
Last modified 7 years ago
#40903 new defect (bug)
Filtered posts_request query can break found_posts query
Reported by: | andy | Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | |
Component: | Query | Keywords: | |
Focuses: | Cc: |
Description
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 ) ) return; - if ( ! empty( $limits ) ) { + if ( substr( $this->request, 0, 26 ) === 'SELECT SQL_CALC_FOUND_ROWS' ) ) { /** * Filters the query to run for retrieving the found posts. *
Note: See
TracTickets for help on using
tickets.
The proposed fix might actually break something for plugins that hook into the
found_posts_query
filter to clear that query.