PHP and WordPress sites

PHP versions

PHP-FPM comes from the deb.sury.org packages. The installer offers 8.1 to 8.5 and defaults new sites to 8.4; more versions can be added later under Services → PHP Runtimes, which offers 8.3, 8.4 and 8.5. A PHP 7.4 installed by hand is recognised for legacy applications but never offered in the picker, never becomes the default and has no restart button. PHP 5.x, 7.0 to 7.3 and 8.0 are refused.

Each PHP site runs in its own PHP-FPM pool, as the site's Linux user, over a Unix socket. Change a site's version at any time from its Settings; the pool moves to the new version and nginx is reloaded.

PHP settings per site

The site's PHP settings are written into its pool as admin values, so the application cannot override them. Each has a preset dropdown; blank means the default.

OPcache is always on, with a server-wide drop-in (192 MB, 30,000 files, revalidate every 2 seconds), and expose_php is off.

Composer is installed on first use at /usr/local/bin/composer with a signature-verified bootstrap, and is always run under the site's PHP version. From a shell as the site user:

cd ~/htdocs/example.com
php8.4 /usr/local/bin/composer install --no-dev

Install WordPress

1. Point the domain at the server, then open Sites → Add site and choose WordPress from the PHP Applications grid or the search box.
2. Enter the domain, the WordPress version, a site title, and the administrator username, password and email (defaults to admin@<domain>). WordPress uses MariaDB; the database and its user are created for you, named wp_ followed by a random suffix.
3. Create. The panel downloads the WordPress core, writes wp-config.php, creates the database and runs the WordPress installer with your administrator details. HTTPS is issued in the background.

Other one-click and assisted applications work the same way: Drupal, Joomla, Moodle, Laravel, Symfony, TYPO3, Matomo, Nextcloud, Gitea and more. Each declares the PHP versions it supports, and the panel refuses to install onto a version outside that range.

Caching

Page cache

Page cache in the site's settings turns on nginx's FastCGI cache for the site: responses are kept for 10 minutes and served stale while a fresh copy is fetched. The panel knows which requests must never be cached: POST requests, anything with a query string or an Authorization header, and requests carrying a logged-in cookie for WordPress, WooCommerce, Laravel, Moodle or Drupal. For WordPress the admin, login, cart, checkout and my-account paths are also excluded.

Purge on the site clears only that site's cached pages, without reloading nginx.

Redis object cache

Redis is one server-wide service on 127.0.0.1:6379, installed on demand from the Instance screen. Enabling the object cache on a WordPress site sets a per-site key prefix and turns on the Redis cache through WP-CLI, so sites on the same server never share keys. Flush runs wp cache flush for that site only; the panel never flushes the whole Redis instance.

From the command line

apcli site create blog.example.com --type wordpress
apcli site create app.example.com --type php --php 8.5
sudo -u <site-user> -i         # a shell as the site user
php8.4 -v

Common messages