cakephp & others: handle PHP 8.1 end of life before it happens by supporting 8.2 instead

[a3s7p]

I found this when working with cakephp but no doubt it affects tons of PHP TKL appliances.

PHP 8.1 is only receiving security updates and scheduled to reach complete end of life in 10 months from now.

However, it seems 8.1 is the latest version supported in common via lamp81 plan.

8.2 seems to be the default version in Bookworm.

We should probably support 8.2 and 8.3 and migrate existing appliances to 8.2 soon.

8.3 has only been released ~1.5 months ago so I would not expect many appliances to have been tested with it yet.

[JedMeister]

As a general rule, PHP from Debian default repos should be preferred - as you note: PHP8.2 in v18/x/Bookworm. Beyond simplicity, my main rationale is that they then get automated security updates from Debian (via our cron-apt config). I.e. in v18.x, if the app supports PHP8.2, then it should be using the lamp plan.

The alternate lamp plans (e.g. lamp81) should only be used when a PHP app needs an alternate version of PHP. Having said that, because of the release timing of Bullseye, we had PHP7.4 at a fairly late stage of it's upstream support cycle. IIRC a number of v17.x apps got newer PHP because they needed it explicitly. Even when the main app itself didn't require newer PHP, many popular apps (e.g. WordPress) have lots of third party plugins that do have newer PHP version requirements. So I suspect that's why you've noticed this in a few apps.

I note that CakePHP 5.x supports PHP8.2. So the default lamp plan should be the one to use.

TBH, looking at the CakePHP build code for v17.x, I'm not completely sure why @OnGle used lamp81? CakePHP 4.x, is being installed, which is compatible with PHP7.4 (Bullseye default PHP) so would have worked with the default lamp plan and technically should have used that. He may be able to give more insight, but I have a vague recollection that CakePHP v5.0 was not yet released but was close (with PHP 8.1 min requirement), so lamp81 was used with the rationale to make it easier for users who wanted to upgrade to latest stable CakePHP during the lifetime of the appliance.

As something of an aside, the current alternate PHP version handling could be better IMO. I've just opened another issue with an idea and be interested in your thoughts - please see #1892.