Selectable PHP options

Feature Discussion
1

I’m starting work properly on the selectable PHP versions, which will install the relevant PHP-FPM from the Sury repo, and handle the setup.

The current plan is to have:

  • selectable PHP versions based on config/php. Unsupported versions will be ignored and reported.
  • auto generated FPM pools with support for manually overriding defaults, with the configurations in /etc/sympl that can then be selected on a per-site basis via config/php-pool.
  • pools will be disabled/enabled automatically.
  • automatic updating of PHP packages via sympl-updater
  • PHP modules installed with the same default set as Sympl has now. Extra ones can be installed manually.

Are there any other must-haves you’d expect for PHP configuration in Sympl?

Currently implemented options:

  • config/php - contains a [major].[minor] version string. Valid versions will cause relevant configurations to be created, invalid versions are (currently) ignored.
  • config/php-fpm - file existence enables PHP-FPM configuration for Apache. Containing false or another string disables this temporarily, dropping to the default mod_php version for the distro.
  • config/php-pool - alphanumeric name for the PHP pool, to allow sites to share FPM pools. Defaults to _default.
  • config/php-user - user to run PHP as, either name or uid (non-system), defaults to 'www-data`.
  • config/php-group - user to run PHP as, either group or gid (non-system), defaults to 'www-data`.
  • config/disable-php-security - similar to how it works with mod_php normally. Not yet implemented on the PHP-FPM setup.
  • sympl/php/<php-version>/includes.d/<php-pool> - editable options to adjust/override PHP settings for a pool.
  • config/php-modules - a list of extra modules to install for the FPM instance.

Nice-to-have options:

  • Your suggestion here!
2 Likes
2

How will command-line scripts be affected? Will each php binary have its own path, e.g. /usr/bin/php-8.0?

I have PHP cron jobs on my server and some popular PHP apps require or strongly recommend them (Nextcloud, Drupal etc.)

3

Would it be possible to have a command line option to get a list of the currently available php versions? Could then expand that to make it interactive and write the version file too as a further iteration.

Similarly could there be a command that gives a summary of site and php versions/settings, and whether there are point releases?

Can the specification support multiple different versions specifications? e.g. 8 would give the latest major version with any point releases auto installed. 8.3 would give the latest bug fix release of the point release. Any further specification would give the exact version for example when needing to pin to a very specific version.

4

Yes, php-cli will be installed, and each will be runnable individually as normal, for example as php8.0 example.php. The normal php will still be the default for the distro itself.

Yes, I’m planning on making it fairly user-friendly, similar to the sympl command-line, with feedback when you specify invalid values.

That should be possible.

Going more granular than point releases is a bit more complex, as the Sury repo doesn’t keep versions indefinitely, and you tend to only have the most recent one in the repo.

As far as specifying a major version number (‘5’, ‘7’, ‘8’, etc) I’m not sure if someone would expect it to be the oldest or newest available version of that branch, but I’m leaning toward the oldest, to avoid compatibility issues appearing from updates.

Specifying ‘8.1’ would then get you the current ‘8.1’ (edit: followed by relevant updates), which would be (at the moment) php 8.1.18.

Pinning more specific versions (ie: sticking with 8.1.18 indefinitely) is more likely to cause security issues later down the line and would lead to headaches if you came to migrate as it probably wouldn’t be available and I’d like to avoid that sort of thing where at all possible, so if you wanted to pin that version then you’d probably need to do that manually.

1 Like
5

Done a bit of an edit on the first post with the options so far - if there are any requests, now is the time!

6

Not a request, but just to say this would be a very useful feature for me - in fact it’s approaching a deal-breaker as many PHP libraries and frameworks won’t support ‘old’ versions of PHP and move their minimum version on a lot faster than Debian does.

1 Like
7

The good news is that this still looks like it should be back-portable to Sympl 10 and 11, and fingers crossed should be in Sympl 12 for launch (and I’ll be working on upgrade info for upgrading to 12 from 10 and 11 after launch).

This feature has been something that’s been on the to-do list for some time but with the acceleration of PHP development and developers starting to require these newer versions, it’s become a must-have.

The good news is that the foundations laid here mean further development of new Sympl functions will be quite a bit quicker.

(also, edit of the first post again!)

2 Likes