2.1.25

Fixed​

• 2.1.24 could stop the panel from starting. Update to this before restarting a 2.1.24 server.
• WP Helper was not installed with WordPress on any server that had updated rather than been installed fresh.
• An update restarted the panel before the step that configures it, so what a release turned on stayed invisible.
• An update never touched the webmail, so no webmail feature ever reached a server that had been updated rather than installed fresh.

Notes​

PHP X-Ray registered GET /api/php/xray/{domain} beside the GET /api/php/{version}/options that was already there. Go's router refuses two three-segment patterns whose wildcard sits in a different position — both match /api/php/xray/options, and neither is more specific — and it refuses them by panicking as the routes are registered. So this was not a broken page. The panel did not start at all, on any server where both features were enabled, at the first restart after updating.

Every test passed, because nothing built a router with every module on it at once. There is now a test that does exactly that, with all 933 route patterns in the tree, and it fails naming both patterns. It was checked the only way worth checking: by putting the old route back and watching it fail.

The same collision had been hit before, in the per-domain PHP version API, and the rule was written down in a comment there. It got walked into anyway. The route has moved to /api/php-xray/.

WP Helper was staged by the installer, and an update never runs the installer — it unpacks the release and copies the CLI and the templates. So the plugin reached fresh installs only, and every updated server said "WP Helper is not staged on this server" on each new WordPress. It is staged by this update, and the panel now also looks in the unpacked release, so a server carrying the release has it either way.

An update restarted the panel when it replaced the binary, and only then rewrote the module list and ran the release's migration. The panel reads that list once, at startup — so what a release turned on was invisible until something else happened to restart it, and usually nothing does. That is not specific to one release; it is why 2.1.24 reported success with ten new modules enabled and every one of their pages answering 404. There is a restart at the end of an update now, and it says so plainly when the panel does not come back.

And the webmail was never updated at all. native-webmail update has existed all along and was called by nothing: the release carries the whole of the webmail, and an update copied the CLI, the templates and the binaries straight past it. Every webmail feature shipped since a server was installed — S/MIME, the calendar, CardDAV, Undo Send, scheduled sending, calendar sharing, PGP — reached servers installed fresh and no other. The update said it had succeeded, and the webmail was the one the customer started with.

Both of those are fixed in the updater that ships here, which means they take effect from the next update: the one that installs 2.1.25 is still run by 2.1.24's copy. On a server updating to 2.1.25, run hitechcloudcli native-webmail update once by hand to pick up the webmail.