PHP

Several PHP versions are installed side by side. You choose which one runs per directory, not per account.

There's no "PHP version" list for the account and no php.ini editor. The version and the settings both come from files in your own home directory, so they stay with your project and survive a move and a restore.

Two ideas explain almost everything here:

• The web server takes the version from the directory that holds the script, reading .htaccess to find it.
• The php command tries to match the web server, looking for the same markers in the directory you're in.

So a site and its command-line tools agree by default; you don't set the version twice.

Choose the version for a site

Put a handler line in the directory's .htaccess. For PHP 8.3:

AddHandler php83 .php

The line applies to that directory and everything below it. The handler name for each installed version is on the PHP pages under Runtimes & Tools.

Name the version on a site that must not break

Without a handler line anywhere, the server's default version applies, and that default moves forward over time.

Which version the php command runs

php in the terminal, a cron job, or a deploy script doesn't necessarily run the default version. It searches the current directory, then each parent up to your home directory, and uses the first marker it finds:

Order	Marker	Contains
1	.htaccess	An AddHandler php83 .php line, the same one the web server reads.
2	.php-version	Only a version number, e.g. 8.3.
3	composer.json	A config.platform.php setting.
4	None	The server default applies.

The order is deliberate: .htaccess wins so the command line matches what the website really runs, as a CMS upgrade or a migration script needs.

.php-version suits a directory with no website: a library, a worker, a small test project. composer.json needs nothing more if your project already pins its platform.

note

.htaccess only counts when the handler is for the .php extension. AddHandler php74 .phtml sets up the web server for those files, but the php command ignores it and keeps searching.

To pin a version regardless of directory

Call PHP by name: php83 script.php. That's the reliable form in a cron job, and anywhere else the working directory isn't certain.

Settings

There's no php.ini editor. PHP reads extra .ini files from two directories in your home directory:

Directory	Applies to
~/.config/php/	Every PHP version.
~/.config/php83/	That one version, here 8.3.

Create any .ini file there, e.g. custom.ini, with the directives you need:

memory_limit = 512M
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 120

PHP reads the per-version directory after the shared one, so it wins where both set the same directive. Keep settings that belong to one version there, so a future upgrade doesn't inherit a setting that no longer applies.

The web server and the php command both read these files, so a setting applies to your site and your scripts alike.

note

Some values are already set for you, and overriding them isn't useful: sessions, temporary files, and uploads point at directories in your home directory.

Extensions and phpinfo

Each PHP version's detail page under Runtimes & Tools lists its loaded extensions and has a Show phpinfo() button.

That output is the definitive answer to "is this extension on?" and "what's the effective value of this setting?", more reliable than working out which .ini file must have won.

The page runs PHP the way your sites run it: as your web user, with your .ini files from ~/.config/php/ and ~/.config/php83/, so it shows the settings your sites get. The one exception is a site directory's .user.ini, which doesn't apply because the page isn't in a site.

If a setting you wrote doesn't appear

The usual causes:

• the file name doesn't end in .ini
• the file is in a per-version directory for a version the site doesn't run

Packages, and commands as the web user

Install a PHP library per project with Composer:

composer require <vendor>/<package>

A command that writes files the website also writes

Run it, e.g. a CMS upgrade or a cache rebuild, as the web user with wsudo. Otherwise you own the new files and the site can no longer overwrite them. Direct sites gives the reasoning.

WP-CLI is already installed, for WordPress.

PHP errors and warnings go to the website's error log, under Logs.