Admin UI Posts: Pagination via offset uses inconsistent sorting for tie-breaks

[msea55]

On the admin ui where posts are displayed by post type, when the user paginates from the first page to the second ties in the sort criteria are not handled consistently. On the site I am working on, I have a post type with 31 posts. Each of the 31 posts has the same exact post date, (all created by a bulk action). In the admin ui, when the user paginates from the first page, to the second (post date is the default sort on this page), some posts appear on both the first and second pages, while others appear on neither.

The WP_Posts_List_Table uses WP_Query::get_posts() which sorts based on either a passed in sort criteria or a default if none is passed in. WP_Posts_List_Table passes in the sort criteria of either whatever column is selected by the user, or nothing if none are selected. A site which doesn't override this behavior could encounter the issue I described. I would ask that either the edit posts query include a fallback secondary sort of ID (though this would have to not override the default if no sort is selected), or that the admin ui post viewer not use get_posts and instead use something that remembers the results returned on the first page when moving to the second.

[pbiron]

Thank you for the ticket.

We are already tracking this issue in #44349.

[msea55]

Thank you @pbiron . I did search for a similar ticket before creating this one, but I didn't find it (or any of the others linked), I guess I just searched the wrong thing. Out of curiosity, I saw the patch linked to that it looks like it only addresses cases where the existing sort contains a numeric field and not cases where the existing sort is just on a string field (for which this problem is less likely to occur but could) or where there is no existing sort, which is my case with the admin ui default sort. Is that being considered or does it make sense for me to add a comment to that thread on the topic?

[pbiron]

Yeah, it's not easy to find that ticket :-)

Actually, that patch is on a different ticket (but one that has the same underlying cause).

As you can see by tracing through the history of all the related tickets, no consensus has yet been reached about the right way to address the underlying problem...because it is difficult to cover all cases in a way that doesn't break some things.

Yes, by all means, add comments and/or a patch to the other ticket!!

[msea55]

Okay. Thanks!