Opened 8 years ago

Closed 7 years ago

Last modified 7 years ago

#966 closed defect (bug) (fixed)

Previous/next page breaks when asked for displaying n days worth of posts

Reported by: excalin Owned by: westi
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)

patch (2.1 KB) - added by excalin 8 years ago.
patch2 (3.4 KB) - added by excalin 8 years ago.
966.diff (1.2 KB) - added by westi 7 years ago.
Fix the query in _max_num_pages

Download all attachments as: .zip

Change History (10)

  • Patch set to No

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.

excalin8 years ago

  • 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.

westi7 years ago

Fix the query in _max_num_pages

  • 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]

Ryan has fixed this another way in [3694]

Note: See TracTickets for help on using tickets.