chore(pm): retire the pre-2013 configuration page

[e107help]

Why

The private messenger ships two admin pages, and only one of them is reachable. plugin.xml declares admin_config.php as the plugin's single admin link (plugin.xml L6-L8), the plugin ships no legacy plugin.php for the old $eplug_conffile route, and nothing in the tree names pm_conf.php outside itself.

It had also stopped working on its own terms. Its include of the plugin's admin language file is commented out (pm_conf.php L112), and the admin bootstrap skips the admin-language load for any plugin that ships a global language file (boot.php L274-L280), which pm does. Nothing defined the ADLAN_PM_* constants the page printed, and an undefined constant is fatal on PHP 8, so the page died on the first one it reached.

What it still held that mattered was a second copy of the orphaned attachment sweep, reading e107_plugins/pm/attachments/ while attachments have stored into the media tree since 2013 (pm_conf.php L792). Keeping the page meant maintaining two wrong sweeps for a screen with no reader.

@Deltik settled this on 2026-09-12: retire the page rather than correct its sweep.

Refs #6159

What Changed

• e107_plugins/pm/pm_conf.php is deleted.
• e107_plugins/pm/admin_config.php keeps its legacy sweep path and its //FIXME wrong path. exactly as they are (admin_config.php L727). Correcting that path is the half of PM attachments are stored in the media tree and deleted from the plugin directory, so every attachment outlives its message #6159 that is not a bot's to take.
• One string was worth rescuing. ADLAN_PM_82 says what happens above the maximum send, that the rest of a send is queued for the cron task, and the retired page was the only screen that showed it (English_admin.php L66). The surviving page left that field's help empty (admin_config.php L144), so the field carries it now.
• Two acceptance-test comments described the retired page's copy of the sweep; they name the surviving one instead.
• plugin.xml takes the date of this commit. The version stays at 3.1, which was already bumped after the last tag.

Nothing else of the page is lost. Its maintenance half was a copy of admin_config.php's, differing in whitespace and a builder rewrite, and the retired copy was the broken one: its maximum-send field posted under the name pm_option-v rather than pm_max_send (pm_conf.php L401), so that setting was never saveable from it. The only pref it edited that admin_config.php does not is dropdown, which nothing reads.

Six admin language entries are left unused by the deletion. They stay: they are captions in an array admin_config.php shares, that file already carried unused keys, and pruning numbered keys from a language file is a tidy with a translation cost and no behaviour behind it.

How It Was Tested

There is no reproduction test, because a page nothing reaches and that fatals on load has no behaviour to red. What the change is measured against instead is what still reads it: a tree-wide search for the file name returns nothing after the deletion, and plugin.xml was already the only thing that decided which page the Configure button opens.

The whole unit suite ran green on PHP 8.5 with MariaDB 10.11, along with PHP lint on the changed files and the downgrade check. The acceptance suite, which is where the two repointed comments live, did not run locally; CI is its first run and the first run of the full matrix.

Backwards Compatibility

Rendered HTML is untouched on every page that survives. No class, method, signature or pref changes, so a theme or a plugin reading the pm prefs sees what it saw before.

A site that upgrades by unpacking a release over its own tree keeps its copy of the deleted file, because core has no obsolete-file list to hang a deletion on. That is not a new hazard: the stale page's sweep reads the same legacy directory the surviving sweep keeps by decision, its prefs form merges rather than replaces, and it fatals on PHP 8 anyway. Whether a retirement like this should reach installed sites through the plugin's upgrade hook is a wider question than this PR, and @Deltik's.

AI Model

Claude Opus 5 (claude-opus-5), as e107help.

Checklist

• Read on master at aa36836 before changing anything
• British spelling, no new comments outside docblocks
• Citations pinned to a commit, not a branch
• Adversarial review run on the diff, and its two findings fixed in place
• Full CI run