General developer forum

PHP 7.2 is going to be End of life on 30th November, however this is creating a (minor) problem for those of us with an LTS release only policy for Moodle, because Moodle 3.5 refuses to upgrade if you have PHP 7.3. I'm not yet ready to deploy Moodle 3.9 to live systems (sometime early next year I hope), however, I'll get my knuckles rapped by the PEN testers if I leave PHP 7.2 on the servers past the end of November and they decide to run a check. So all systems have already been tested and upgraded to PHP 7.3 with no obvious ill effects on Moodle (this is a high volume system, so somebody would notice!). I've patched Moodle to stop it complaining about PHP 7.3 during the upgrade. While I appreciate that fully validating Moodle 3.5 on PHP 7.3 may not be worth the effort for an old release that will be EOL next year, this does place anybody who doesn't have the skills to patch the code and isn't ready to upgrade in a situation where they either can't upgrade Moodle, because PHP 7.3 blocks it, or you have to stick with PHP 7.2 after it's EOL. Neither strikes me as a good choice from a security perspective. I would argue that it is preferable to provide an option to allow the user to install/upgrade on unsupported PHP versions, perhaps limited to one higher than the officially supported version in order to account for this, since I suspect the same issue will arise with Moodle 3.9 when the time comes. The other option might be to allow upgrades of existing Moodle installations to proceed if the PHP version is only one above the supported one (with a warning), but to block new installations, thereby encouraging people making a new deployment to pick a later Moodle release.