[albertlast]

Description

The page for choosing which posts to split off a topic lists them in no particular order on PostgreSQL.

All four queries behind it (TopicSplit, the page itself and its xml refresh, for the selected and the not selected lists) only added ORDER BY when the member views topics newest first:

' . (empty(Theme::$current->options['view_newest_first']) ? '' : 'ORDER BY id_msg DESC') . '

Otherwise the order was the database's choice. MySQL happens to return InnoDB rows in primary key order, which is why this has gone unnoticed since 2.1 (v2.1.7 has the same line). PostgreSQL returns rows in the order they sit in the table, and an UPDATE writes a row's new version at the end, so a post that has been edited is listed after the posts that came after it. Because the same queries use LIMIT, the order also decides which posts land on which page of the list, so a post can appear on two pages and be missing from another.

The queries now always order by the message id, descending for members who view newest first:

ORDER BY id_msg' . (empty(Theme::$current->options['view_newest_first']) ? '' : ' DESC') . '

Test

TopicSplitTest posts a topic and two replies through the posting form, edits the first post in the database, and checks the split page lists the three oldest first. The edit is what makes PostgreSQL misorder the list; on MySQL the test passes either way. Without the change, on PostgreSQL:

the posts to split are not listed oldest first
-    0 => 248,
+    0 => 250,
     1 => 249,
-    2 => 250,
+    2 => 248,

With it, it passes on both MySQL and PostgreSQL.

Found while building the template snapshot tests in #9712, where the split page's snapshot changed order on PostgreSQL between two runs.

Issues References (Fixes|Related|Closes)

Related: #9712

🤖 Generated with Claude Code