Pagination skips entries with same timestamp |
|||
|---|---|---|---|
| Date: | 06/11/2008 | Severity: | Major |
| Status: | Resolved | Reporter: | hearsay |
| Version: | EE 1.6.3 | Assigned To: | Not Assigned |
| Keywords: | Modules, Weblog | ||
Details
I quickly published some weblog entries by using copy and paste, and so they had the same time stamp down to the minute. My client noticed, when testing the website, that the pagination (prev/next) links were skipping some articles, and it seemed to be skipping those that were published within the same minute. I edited the published time and gave each entry an incrementally higher number. The pagination links don’t skip any entries anymore.
Comment on Bug Report
| Posted by: Derek Jones on 11 June 2008 11:35am | |
|
Thanks for the report, hearsay. This is, however, not a bug, but the behavior of those tags with identical timestamps down to the second. From the user guide:
The date of the entry is used to sort, and when they are identical, you may get some undesirable results. This would make a good feature request to allow another method of sorting, but at present, these tags are working as intended. |
| Posted by: hearsay on 11 June 2008 11:39am | |
|
Hmm… ok, thanks. I figured it sorted by time, but my guess was that the bug was in that it only sorted down to the minute. If it does down to the second, then that makes more sense, but now I’m trying to figure out how I submitted three entries at the exact same time. |
| Posted by: Derek Jones on 11 June 2008 11:45am | |
|
|
Did you use the Clone Entries extension perhaps? Or cut and paste the human timestamp? |
| Posted by: hearsay on 11 June 2008 11:48am | |
|
|
No, just cut and pasted one entry’s content from a text file, submit, and repeated. The pagination links ended up skipping over two of them, apparently only noticing the first of the three with the same minute. |
| Posted by: Derek Jones on 11 June 2008 11:54am | |
|
|
They would have had to have had the same seconds as well, as the query looks for > the entry date or < the entry date, depending on whether it’s checking for the next or previous entry. Unix timestamps are stored in the db, which are in seconds. Not sure in your specific case what triggered that, but editing the minute would have the desired effect as well. |
| Posted by: hearsay on 11 June 2008 11:58am | |
|
|
Hmm, alright. Thanks for your help! Sorry to tie up the bug tracker with a non-bug! |
| Posted by: Derek Jones on 11 June 2008 12:03pm | |
|
|
Not a problem, hearsay, we’re happy to help! |
| Posted by: Derek Allard on 12 June 2008 10:49am | |
|
Heresay, just as a followup after some digging we discovered a situation where identical timestamps could occur through normal publishing. We’ve have addressed it, and also modified the next/prev tags so that in those cases, entries will not be skipped. This will be part of the next build, but if you’d like to run a sample of the file, feel free to email me and I’ll provide it to you. |
| Posted by: pink-fu on 1 July 2008 9:03am | |
|
|
i don’t like the way you’ve fixed this issue in the 1.6.4. version. in the 1.6.4. the entries should have increasing entry_id with increasing date to properly show the prev/next entry navigation. what if i publish an entry to the past date? e.g. i’ve now added entry for july 2007, but the entry_id is automaticaly the latest one. This brokes my prev/next entry navigation.
I’ve right now two posibilities:
I don’t wish make any of these two. |
| Posted by: Derek Jones on 3 July 2008 10:47am | |
|
|
The date is still what is used to determine the pagination order, pink-fu. The entry_id is a secondary sort that MySQL will only use when the entry_date has a collision (an exact match). If you are having order and sorting problems, please post to the support forums and our Technical Support Specialists can assist you in resolving your issue, and if need be, reopening this bug report. |