WebHostPro 0.14.2

Minor​

• The guided tour's texts are proofread in English and Polish: the steps describe the standard ports, what each button does, and the DNS and DHCP checks more clearly. The other languages follow the corrected English.
• A correction to the 0.14.0 note: after the first-run question the tour opens by itself once per browser, and the DNS step says only that this DNS server is unavailable while the NAS is off. Devices can still use names they have cached.

Minor​

• The tour's step on DNS for your network says what is actually wrong: TurboDNS answering your own domains only, TurboDNS not reaching the internet's DNS servers, or nothing answering on the LAN's address now each have their own text.
• The tour reads the NAS's own DNS setting only from where QTS 6.1 keeps it (Network & Virtual Switch's setting); an older key that QTS no longer updates could have told a correctly set NAS to set Manual first.
• The way back from the takeover puts QTS's Web Server back before its administration, so the administration restarts with every port of QTS's as it was.

Major​

• A guided tour. Tour in the status bar opens a small panel that walks through the panel in order: the usual ports (and the takeover), TurboDNS first, the first site, the dry run and Apply this plan, the site's checklist, and DNS for your network. Each step opens its page and rings the control it means; the tour never clicks anything. A fresh install opens it once, after the first-run question.
• What each step says follows this NAS: whether QTS's servers hold 80 and 443, whether TurboDNS is installed and answers names outside your zones, and how the NAS's own DNS is set in Network & Virtual Switch. The tour suggests your router's DHCP only when TurboDNS answers every name and the NAS's own DNS is Manual with a server that is not the NAS; otherwise it says what to set first. It also says what happens when the NAS is off: devices then get no names at all.

Minor​

• The way back from the takeover (and the package's removal) puts back the route blocks of Rtorrent 16, SDLV and TuneThatHue in QTS's administration as they are at that moment. 0.13.0 put back the copy from the time of the takeover, so a package that had changed its block since (a new release, another port) got the old one back.

Major​

• WebHostPro can take over the NAS's web server role in one click. While QTS's own servers hold ports 80 or 443, the Front and ports page offers "Take over 80 and 443": QTS's administration over HTTPS moves from 443 to 44443 (or the next free port), QTS's Web Server and its virtual hosts from 80 to 8880, each step checked before the next, QTS's virtual hosts come in as sites behind WebHostPro, and WebHostPro takes 80 and 443 in one apply.
• The result lists each port from and to, says whether each imported site answers as before, and gives QTS's new administration address and the apps it serves under a path (such as Rtorrent 16 and SDLV). QTS's administration on port 8080 stays where it is.
• A step that fails puts back everything changed before it. "Give 80 and 443 back to QTS" puts QTS's servers on their ports again, removes the sites the takeover imported and moves WebHostPro to its own ports. If one of QTS's ports was changed by hand since the takeover, it stops and names the setting.
• A fresh install asks once after the first sign-in: "Make WebHostPro this NAS's web server?" An upgrade never asks.

Minor​

• QTS writes its administration's list of app paths again when it restarts the administration, which drops the route blocks Rtorrent 16, SDLV and TuneThatHue add there; the takeover and its way back put them back right after, once QTS's proxy accepts them.
• A QTS virtual host whose name WebHostPro cannot take (an underscore, or a site here with that name) is named in the plan and answers on the Web Server's new port only.
• Removing the package puts QTS's administration and Web Server back on their ports when a takeover is in place.
• Another program on 80 or 443 is never moved: the page names it and shows the steps that free the port.

Major​

• A PHP site can have PECL extensions of its own. On the PHP tab, under Your own extensions, name a package from pecl.php.net (and a version, if you want one) and press Build: it is compiled for the PHP version the site runs, as the site's own account, with no network, in Bucket & Code Server IDE's builder environment, one build at a time on the NAS. The page shows the build's state and its log.
• Every build is checked before anything can load it: a PHP extension for the NAS's processor, every library it needs from glibc or the package, nothing newer than the package's glibc. It is kept as root's file, so the site's own account cannot change what its PHP loads.
• Tick it, save, then a dry run and apply: the site's PHP-FPM workers load it after they have switched to the site's account (never the root master), and its scheduled tasks load it too. Other sites never see it.

Minor​

• The package keeps PHP's own headers for this (about 5 MB more), since only the package's own copy matches the PHP it runs.
• Building needs Bucket & Code Server IDE with a builder environment (debian12-builder or ubuntu2404-builder); without one, the tab says so.
• Perl modules and server modules are not part of this yet: the package has no Perl, and a server module is a server-wide change for the admin, not a site's.

Major​

• Apache sites' .htaccess files can use four more modules: Digest authentication (AuthType Digest with a file from htdigest), groups from a plain group file (AuthGroupFile and Require group), Substitute to rewrite text in a page as it goes out, and the RATE_LIMIT filter with SetEnv rate-limit to cap a download's speed. They are compiled into httpd, so they work right after the upgrade, with no apply.
• The default site's page has the Cache tab with its own Valkey and memcached sockets, as every PHP site's page.

Minor​

• httpd can load a module built for it later (mod_so, with apxs in the app), and nginx is built --with-compat for dynamic modules. No site uses either yet.
• Server-Side Includes stay off: they need an Options line that a site's .htaccess may not set. PageSpeed is still not offered: the project was retired in 2023, and its nginx module does not build with nginx 1.23 or later.

Major​

• Every PHP site has its own Valkey (it speaks Redis's protocol) and its own memcached, on sockets that only that site can open, so neither needs a password or a network port. The site's Cache tab shows both sockets.
• imagick in PHP 8.1 to 8.5, with ImageMagick 7.1.2 reading and writing JPEG, PNG, WebP, GIF and AVIF and reading HEIC. The package's own policy refuses SVG, MSL and the other formats that read other files or run programs.

Minor​

• After the upgrade, one dry run and apply on the Sites page starts the sites' cache servers and loads imagick.
• Each cache server keeps up to 64 MB and starts empty after a restart, so sessions and queues belong in the database.
• The Send a test e-mail button is gone; failure reports still come the same way.
• The licence texts of ImageMagick, libheif, libde265, libaom and the PHP extensions are in the package.

Major​

• Scheduled tasks for each site: a PHP file of the site, a command or the site's own address, on a preset or the five cron fields. A task runs as the site's own account with the site's PHP settings.
• Run now, Stop, the last result with its output, and a task log for each site.
• MailServerPro on the same NAS mails a report when a task starts failing, then at most once a day while it keeps failing.

Minor​

• A task needs no dry run, and the upgrade changes no site.