[3.0] Load the SplitTopics template for the page that needs it

[albertlast]

Description

Splitting a topic does not work at all on release-3.0. Clicking Split Topic under any post gives "Unable to load the ask sub-template", because the ternary in TopicSplit::execute() is inverted:

Theme::loadTemplate(!isset($_REQUEST['xml']) ? 'Xml' : 'SplitTopics');

An HTML request has no xml, so it loads Xml; the XMLHttp request loads SplitTopics. 2.1 has if (!isset($_REQUEST['xml'])) loadTemplate('SplitTopics');, which is the other way round.

Because nothing could get past that, two more faults were sitting behind it:

• The select-posts screen was a 500. num_messages arrives from COUNT(*) as a string, and messages_per_page comes from modSettings, so both were rejected by PageIndex::__construct()'s typed int parameters. Display.php already casts the same setting at its own PageIndex call.
• A resubmitted split was a 500. $split2_first_msg/$split2_last_msg are only assigned inside a loop over a query that returns nothing once the messages have moved to the new topic - which is what pressing Split a second time, or using the back button, looks like. Board::getMsgMemberID() then received null. The "No database changes yet, so let's double check" test a few lines further down exists to catch exactly this, so these now start at 0 and it does; the page is the intended cant_find_messages error instead of a fatal.

How to test

On release-3.0, open any topic with more than one post and click Split Topic in a post's More… menu.

• Before: "Unable to load the ask sub-template" (or a 500 when splitting at the first post).
• After: the ask screen renders. All three options work - only this post, this post and all after, and select posts, including the two page indexes on the select screen. Pressing Split twice gives "Unable to find messages" rather than a fatal.

Verified on MySQL; the change is not SQL.

Issues References (Fixes|Related|Closes)

Found while sweeping the topic display for the #7933 split.