get_adjacent_post won't find any posts that are published in the same minute

[sheepysheep60]

get_adjacent_post won't find any posts that are posted in the same minute, even if they are technically posted before or after the other post.

This sounds silly but if you use a clone function to create multiple posts for a website, then you you can't navigate them using links created with get_previous_post or get_next_post.

[talldanwp]

Thanks for reporting @sheepysheep60. We discussed this during a triage session in slack (​https://wordpress.slack.com/archives/C02RQBWTW/p1601963248296700) and agreed this looks like a bug, it was mentioned in the triage that the cause seems to be:

because get_adjacent_post uses WHERE p.post_date > $current_post_date?
Probably need to make it a >= and then ORDER BY p.post_date, p.ID

[engahmeds3ed]

@talldanwp I don't think this can solve this issue, I applied this approach and another approach and I think this won't completely solve this issue, plz check the following video recorded: ​https://www.youtube.com/watch?v=ASMoo0RmXkM

[peterwilsoncc]

I haven't had the chance to test this but I think it could be solved by one of two approaches:

• change the clause to WHERE p.post_date >= $current_post_date AND p.ID != $current_post_id ORDER BY p.post_date, p.ID
• use the WHERE clause @talldanwp suggests above and use PHP to remove the current post ID

For previous posts, the clause would need to be reversed.

[engahmeds3ed]

Replying to peterwilsoncc:

• change the clause to WHERE p.post_date >= $current_post_date AND p.ID != $current_post_id ORDER BY p.post_date, p.ID
• use the WHERE clause @talldanwp suggests above and use PHP to remove the current post ID

I tried both solutions on this video ​https://www.youtube.com/watch?v=ASMoo0RmXkM and I think this generates another issue.

The date operator changed to include equals.
A post id operator was added.
In the where clause, we ensure that the post id is not equal to the active's one.
We order by post id.

Trac ticket: https://core.trac.wordpress.org/ticket/42936

[dpantazis]

Hello there! I applied a possible fix. Please take a look on my pull request here ​https://github.com/WordPress/wordpress-develop/pull/617

Thanks!

After further testing, I found out that my previous patch for this issue would work only if we could assume that smaller post ID equals older post date, which we should not.
In this patch, we use a dynamic LIMIT Clause. The limit is being determined by the number of posts with the same post_date.
We use wpdb::get_results instead of wpdb::get_var.
We determine the next or previous post ID based on the position of the active's post ID in the array of the results.

Trac ticket: https://core.trac.wordpress.org/ticket/42936

This PR is an updated version of ​https://github.com/WordPress/wordpress-develop/pull/619 which mainly focuses on the case where $excluded_terms is not empty.
When the active post's term(s) is included in the $excluded_terms, the active post id is not included in the $results of $wpdb->get_results(). In that case, we should return the first post ID inside the $results array if it exists.

Trac ticket: https://core.trac.wordpress.org/ticket/42936

[oglekler]

There is no way to get rows in the same order in which they are stored in a database for sorting purposes.

The solution can be is to get all ID's with the same post_date and if they're more than one, for the previous post take the previous in this result if it exists, and if not - get the post with a date less than the current date, and exactly the same process for next post. An alternative solution could be to check the post_date before save / update and make it unique by adding some amount of milliseconds.

[hellofromTonya]

Per core scrub today, this ticket is related to #47642 and #44349. Helen proposed:

Should probably lump those together and see if somebody is interested in targeting a 5.7-early fix

[ramon fincken]

Patch added in https://core.trac.wordpress.org/ticket/47642#comment:20

[poena]

As suggested, further testing and work can be done in https://core.trac.wordpress.org/ticket/47642

[peterwilsoncc]

This is been worked on with #47642 which has been moved the 5.8 milestone. I'll move this to match and assign to @johnbillion in line with the other ticket.

[hellofromTonya]

Punting this ticket to 5.9 as #47642 was also punted.

Question: Should this ticket be closed as the work is being done in #47642?

[hellofromTonya]

#47642 has been moved to Future Release. Keeping this ticket open to ensure it does get resolved when #47642 is resolved.