VortexPanel v3.4.12 — Release Summary

WP Toolkit installs would hang indefinitely with no feedback. The entire install — WordPress download, database creation, wp-cli setup, vhost creation, cron configuration — ran as a single blocking request, genuinely capable of exceeding gunicorn's 120-second worker timeout under real network or disk conditions. A killed worker gives the browser nothing at all, which is exactly what "stuck, nothing happens" looks like. Converted to a background job with real status polling, matching the same pattern already proven for App Store installs and Panel Update.

Creating a new site with "Create Database" and "Create FTP Account" checked did neither. Confirmed directly: the frontend was sending both flags correctly, but the backend never read them — not new to this update, a pre-existing gap. Wired both to the existing, working database and FTP creation logic, with the site itself never failing just because these optional extras do.

A live crash in database user creation. While fixing the above, found that _sql_escape() was called nine times across create_db, create_user, change_password, drop_user, and grant_db — but was never actually defined anywhere in the file. Any ordinary "create a database with a user and password" request was throwing an unhandled 500. Verified this crashed live before fixing it, then verified the database, database user, and FTP account all genuinely exist afterward.

Security update apply looked like it was doing nothing, over and over. For kernel and firmware packages specifically, apt genuinely installs the new version, but the running kernel/module stays active until reboot — and the panel had no way to distinguish "this actually needs a reboot" from "this failed." Added real detection of Ubuntu's own /var/run/reboot-required signal, with a clear explanation in both the result panel and the toast notification instead of an endless-looking loop.

phpMyAdmin's PHP version and port settings only worked on nginx. The install script itself correctly detects and configures nginx, Apache, or Caddy — but the Save actions for both settings were hardcoded to check only nginx's config path, failing with "Config not found" for anyone running Apache or Caddy. Tested against real config files for all three web servers before and after the fix. Also hardened the install-completion check, which previously only verified a directory existed — created in the very first install step, before any real work happened — rather than checking for the actual config file that only exists once installation genuinely completes.