Ticket #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
Change History
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.
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.
- Owner changed from anonymous to westi
- Status changed from new to assigned
- Severity changed from enhancement to normal
- Milestone set to 2.1
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
- Status changed from assigned to closed
- Resolution set to fixed
Ryan has fixed this another way in [3694]

