get_next_post, get_previous_post do not work for posts posted within same second

[whoismanu]

if you have posts that are published shortly one after the other (e.g. through a script or plugin that posts several posts at once) several of them may end up having the same post_date in the wordpress database table. this is due to the fact that mysql datetime seems to only maintain a precision of one second (see also this discussion: ​http://bugs.mysql.com/bug.php?id=8523).

the problem now is that wordpress functions like get_next_post/get_previous_post (get_adjacent_post resp.) will no longer work correctly if something like this happens as they solely rely on a comparison of the post_date field and they don't treat the case where these timestamps are the same for several posts. the result is that e.g. get_next_post will pick one of the posts having the same timestamp and "jump" over the others, so the user will never see them.

i see two possibilities around this 1.) treat cases with the same post_date by e.g. looking also at the post id (assuming it is always strictly increasing) or probably preferably 2.) make sure that no two posts have the same post_date timestamp by e.g. increasing post_date artificially when publishing the post and if another post already has the same timestamp.

Ooof, unless I'm missing something, this is a tricky patch.

The trick is to change the older/newer operator to older/newer OR exact same time AND not the same post ID. That makes the same-time post show up in the next/prev links, but the problem is you then get stuck in a loop, i.e. you go from post A to post B and back to post A. You also can't do a less-than/greater-than on the ID because IDs don't necessarily correspond to the datetime (i.e. you could have older posts with IDs both higher and lower than the current post).

As I said, seems to be pretty hard to get it not stuck in a loop.

I'd say wontfix/plugin material.

the case would only arise when the publishing of posts is automated. it can, and should, be dealt with by whichever tool is used to publish the post in the first place -- it makes no sense to publish two posts in one go anyway...

It could also be caused by publishing a group of drafts via QuickEdit too i think.

A 2-part conditional such as this could work however

(IRC) DD32	Needs to have an order with an ID, and a conditional for ( ( postdate == now && ID < currentID ) || postdate < now)

See patch. :)

Two minds are indeed better than one. Props DD32 for the inspiration.

Fix mistype (I had %s instead of %d)

Let's finally test this and fix this.

Marked #12650 as a duplicate. Is this patch still good? I noted in the other ticket that I'm not sure you can rely on the ID, but it's better than skipping the post all together.