#16450 closed defect (bug) (invalid)
query_posts problem with pagination
Reported by: | danielpataki | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | minor | Version: | |
Component: | Query | Keywords: | |
Focuses: | Cc: |
Description
I am not sure if this is a defect or my incorrect use of query_posts, here's the scenario, so someone more experienced can decide :)
We have a few custom post types on our site, and I have built some filter options for them, using query posts to modify the loop where necessary. For example, when visiting oursite.com/products/ you see a list of all products (query_posts isn't used). If you filter these results, you could arrive at oursite.com/products/?reviewer=5 which would show all products reviewed by user id 5 (a function converts the reviewer=5 part to the proper string needed in the query). It works fine with paging as well, so oursite.com/products/pages/2/?reviewer=5 works as expected, if there is a 2nd page.
However, I ran into a problem with a special post type. We hold online seminars, and I am using the post date to indicate the time of the seminar. So I have set a seminar to be published in the future on May 5 for example, and I have modified the query like this: "post_type=webinars&post_status=future&order=ASC"
This works fine as well, but if you go to oursite.com/webinars/page/2 it does not show anything, it doesn't even use the same page template (archive-webinars.php), it reverts to index.php.
It seems to me that this is because Wordpress checks if there are any results for the default query when rendering a page. We currently have 5 seminars which have been finished, and 23 which are in the future. By using this string to modify the query: "post_type=webinars&post_status=future&order=ASC" we correctly get a list of 10 upcoming seminars, but when we go to page 2 wordpress seems to revert to index.php because it sees that there is no page 2 for the original query since there are only 5 past seminars.
I am reasonably sure that I am using the query_posts() function well because it works flawlessly for post types where the default query is not changed, only when someone wants to filter results.
I hope that was clear, if someone could determine if this was me using the query_posts() function stupidly or an actual defect that would in itself be helpful :)
Change History (5)
#2
in reply to:
↑ 1
@
14 years ago
Replying to dd32:
The simple response here, Is to not use query_posts.
You'd be far better off modifying the request before WordPress handles it, for example, on one of the filters such as
pre_get_posts
or perhaps one of the others (Its late, I apologise) such as parse_request (which may not be the right time).
As you've found, using
query_posts
requires 2 queries, which means the first query basically needs to have the same contents (Remember, WordPress has not loaded, nor knows about the code in the template files at the time of 404'ing), If you modify the request before it's sent to the database, then a 404 will literally only occur when the query was empty..
Oh what an awesome response, thank you! For some reason it never occurred to me to use a filter, God knows why. I will close this if I can, since using a filter like you said is definitely the way to go and this is not a defect for sure, thanks so much!
The simple response here, Is to not use query_posts.
You'd be far better off modifying the request before WordPress handles it, for example, on one of the filters such as
pre_get_posts
or perhaps one of the others (Its late, I apologise) such as parse_request (which may not be the right time).As you've found, using
query_posts
requires 2 queries, which means the first query basically needs to have the same contents (Remember, WordPress has not loaded, nor knows about the code in the template files at the time of 404'ing), If you modify the request before it's sent to the database, then a 404 will literally only occur when the query was empty..