#36889 closed defect (bug) (invalid)
WP_Query 'post_limits' filter conflicting with 'posts_per_page' parameter
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Milestone: | Priority: | normal | |
| Severity: | normal | Version: | 4.5.2 |
| Component: | Query | Keywords: | |
| Focuses: | Cc: |
Description
If I hook in 'post_limits' or 'post_limits_request' to set a different limit and then query using 'posts_per_page'. the max_num_pages variables will follow the 'posts_per_page' param and not the 'post_limits' filter.
<?php // supposing I have 10 published posts in the DB add_filter('post_limits', function($limit) { return 'LIMIT 0, 1'; }); $query = new WP_Query(array('posts_per_page' => 5)); var_dump($query->max_num_pages); //=> It will be 2, should not be 10 because I am forcing LIMIT 0, 1?
My question is what it should be the correct behaviour? Obey the 'post_limits' filter? Obey the 'posts_per_page' parameter?
Change History (3)
Note: See
TracTickets for help on using
tickets.
Hey @romulodl and welcome to trac!
Filters such as
post_limitsare sufficiently low-level that it's unrealistic to expect the resultingWP_Queryto know about what has happened at the SQL level.As far as
WP_Queryknows, it's paginated to 5 posts per page, and it's been told there's 10 results. It can't really be expected to parse the SQL and figure out that it's changed, just the same as all the query variables don't update to reflect extra conditionals added through theposts_where_pagedfilter.It's entirely possible that the function hooked to the filter could use the instance passed as the 2nd parameter to the filter to manipulate the
WP_Queryinstance to make it aware of the new parameters.But I'd suggest the for 99% of cases, including the example here, using
pre_get_poststo alter theposts_per_pagewould be the much smarter move, leaving the SQL filters for literal last measure when needing to alter the underlying query.I'm marking this as invalid, as I don't think we need to write a SQL parser just yet :)