[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 ) )
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.
*
}}}
--
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