[albertlast]

Description

Backport of #9714.

The page for choosing which posts to split off a topic lists them in no defined order on PostgreSQL. All four queries in SplitSelectTopics() (the selected and not-selected lists, each in the page and in its xml refresh) only added ORDER BY for members who view topics newest first:

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

Otherwise the order was up to the database. MySQL happens to return InnoDB rows in primary key order. PostgreSQL returns them in the order they are stored, and an UPDATE writes the row's new version at the end, so an edited post is listed after the posts that came after it. The same queries use LIMIT, so the order also decides which posts land on which page: a post can appear on two pages and be missing from another.

They now always order by message id, descending for members who view newest first:

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

Testing

Checked on a freshly installed release-2.1 forum on PostgreSQL 17, with a topic of three posts (4, 5, 6) whose first post was then edited in the database:

	not selected	after moving 6 and 4 across
before	5, 6, 4	selected: 6, 4
after	4, 5, 6	selected: 4, 6
after, newest first	6, 5, 4	selected: 6, 4

MySQL showed the right order before and after, as expected. Nothing in log_errors.

Issues References (Fixes|Related|Closes)

Related: #9753, #9714

🤖 Generated with Claude Code