Opened 8 years ago
Last modified 8 years ago
#40903 new defect (bug)
Filtered posts_request query can break found_posts query
| Reported by: |
|
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_queryfilter to clear that query.