#966 closed defect (bug) (fixed)
Previous/next page breaks when asked for displaying n days worth of posts
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| Priority: | normal | Milestone: | 2.1 |
| Component: | General | Version: | 1.5 |
| Severity: | normal | Keywords: | bg|has-patch |
| Cc: | excalin |
Description
My blog showed incorrect "next page" links generated by posts_nav_link, which led to 404 errors. After a lot of research (I'm not familiar with wordpress code) I've discovered that the calculation for the correct number of pages is not done when n days of posts per page is selected (in posts_nav_link, $max_page is set to 999999).
It would be great if this restriction could be lifted, or at least some comments were put there in order to warn users.
As a side note, Kubrick uses 2 or 4 calls to posts_nav_link per page ; this seems a bit like an overkill. It would be great if a more general function could be supplied, which would better serve Kubrick.
Attachments (3)
Change History (10)
There has been some changes in wp-includes/template-functions-links.php, so my previous patch no longer works. Also, I've noticed code duplication between
posts_nav_links and next_post_links (although both do not return the same result in "days" mode...). This new patch factors the code between the two functions, and returns the correct number of posts (but with the same ugly hack, sorry for this: the problem if in parsing $request anyway).
Please consider this patch, as it solves the problem (even if not in a really clean way).
I don't think bug 1091 is really the same as this one. In the current code, posts_nav_link estimates there are always 999999 previous posts, so the link should always be displayed.
- Milestone set to 2.1
- Owner changed from anonymous to westi
- Severity changed from enhancement to normal
- Status changed from new to assigned
Accepting this ticket - Found a similar issue to this while testing paging of categories when in show "n" days rather than show "n" posts mode.
Current issue is that when in show "n" days of posts mode builds invalid queries for finding the max number of pages when trying to view category archives.
- Keywords bg|has-patch added
Attached patch fixes the query and drops and unused variable.
Test Away
- Resolution set to fixed
- Status changed from assigned to closed
Ryan has fixed this another way in [3694]

The right way to count the number of pages in "days" mode is to agregate similar post days together. An SQL instruction such as "DISTINCT DATE_FORMAT(post_date, \'%d %m %Y\')" in posts_nav_link works.
Unfortunately you still have to strip constraints about the postdates created by get_posts in "days" mode. To solve this I'm using an ugly, hackish solution. I put the constraints between comments in the SQL request, and I remove everything between the comments in the counting function. I hope you will find something cleaner.