#19728 closed enhancement (wontfix)
WP_Query should constrict 'paged' to be within bounds of found_posts
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | Query | Keywords: | |
Focuses: | Cc: |
Description
I apologize in advanced if this has been reported before. My Trac search did not find anything pressingly relevant.
WP_Query allows the user to pass in a discrete value to use for the 'paged' parameter; however, often times this value will be dynamic rather than static (as in the programmer will have paged be the value of $_GET[ 'paged' ] or something similar).
The problem is, if you enter an absurdly large or small value for the paged parameter and it's out of bounds, it will just throw a 404 (or otherwise show that there are no posts matching the parameters). I propose that WP_Query automatically changes the paged value to be within the bounds of the returned number of pages.
For example, constrict paged to the following rules:
1 <= $paged <= $wp_query->max_num_pages (where $wp_query is whatever custom query is being used). If the user types in a page larger than the max, it uses the max instead. Conversely, if they type a page less than 1, it uses 1.
The only potential problem I see with this is if a user actually (for whatever reason) wanted a 404 to display when an invalid page was visisted. In this case, perhaps we can introduce a new option to WP_Query such as 'limit_to_bounds' => true?
Change History (4)
#2
@
13 years ago
I agree with you that it's simple enough to perform this fix at the theme/plugin level, but I think it would be nice to at least have the option to have bounded results returned natively. Rather than changing the default functionality of WP_Query, a newly introduced option such as 'limit_to_bounds' with a default of 'false' would provide 100% backwards compatibility. It also wouldn't have to slow down any query that doesn't use limit_to_bounds, since WP_Query would only need to run a second query if limit_to_bounds was true.
#3
@
12 years ago
- Milestone Awaiting Review deleted
- Resolution set to wontfix
- Status changed from new to closed
This is a flaw in the way you are calculating paged
for the request. If you are calculating paged
based on the known size of your result set, you're probably good. FOUND_ROWS()
can be turned off per query, so the bounds may not be known, which means you nor WP can guess the proper amount of pagination.
As it stands to my rather limited understanding, passing an overly high 'paged' value results in a SQL LIMIT being used which causes MySQL to return no rows/posts and the 'found_posts' value on which 'max_num_pages' is based is only available after this initial query, so WP_Query would have to perform a second query to retrieve in-bounds posts.
'paged' values less than 1 are already corrected for in
get_posts()
before the initial query is constructed.I don't really see why this should be the role of core, not least because it would change the expected output. If it's desirable to always have posts found, then it'd be straightforward enough to check for this and re-perform the query at theme/plugin level.