Most web servers do not have a single PHP version. Instead, they offer a number of different PHP versions. The PHP version you see on your hosting control panel is most usually NOT the only PHP version available on the server; it is merely the PHP version used to run the hosting control panel itself.
This makes perfect sense if you think about it. The PHP project publishes a new version every year, usually around late November to early December. Each PHP version has some backwards incompatible changes compared to the previous one i.e. some things that used to work may now display a notice, warning, or flat out fail to execute. Each PHP version is supported for a total of three years: two years of full updates (bug fixes and security fixes), and one year of security fixes only.
Unlike us, most developers do not support the latest version of PHP right away. That's why your hosting company needs to give you access to different PHP versions: to let you update the PHP version used with your site and your CRON jobs whenever you are ready.
Further to that, there is no single “PHP version for the site”.
You can set up the default PHP version used by the web
server typically using .htaccess
files, or by setting this up on your hosting control panel. This may
apply to the entire hosting account, a specific subdomain, or even a
specific directory – either way, it will NOT apply to CRON jobs. To change the PHP
version used by the CRON jobs you will have to edit the CRON job and
change the PHP CLI executable you are using there – which will, of
course, NOT change the PHP version
used by your site when accessed over the web.
For Akeeba Solo this can lead to separate PHP versions being used on your installation: the one used for each one of your CRON jobs, and the one used to run Akeeba Solo itself.
For Akeeba Backup for WordPress this can lead to even more
separate PHP versions being used: the one used for each one of your
CRON jobs, the one used by your site's public frontend, and the one
used by your site's administrator
(wp-admin).
As a result, and depending on how you access your Akeeba Backup / Akeeba Solo installation, you may be running it under a different PHP version while you are still on the same site. This can cause some problems which you may perceive as “bugs”, but are really not. They are the consequence of your being inconsistent with the PHP version you are using.
Each version of Akeeba Backup / Akeeba Solo has a minimum PHP version requirement. This means that our software needs this or a later PHP version to function at all. That is because certain features of the PHP language we are using are not available in earlier versions. We have to update the minimum requirement every 2–3 years when supporting newer PHP versions requires making changes which are incompatible with older PHP versions.
If Akeeba Backup is executed under a PHP version which is older than the minimum requirement, it will simply refuse to run. If the PHP version is way too old (older than PHP 7.1 for versions of our software requiring PHP 7.4 or later, for example) it will cause a PHP error; that's because even the small bit of code which checks for the PHP version is written with PHP language features not supported by PHP versions which became End of Life more than 5 years prior to the date our software was released, something which is rather reasonable (you should never use ancient, abandoned PHP versions in production!).
Therefore, if you get a PHP compilation error running our software, the problem is that you are accidentally executing it under an ancient version of PHP.
Moreover, if our software appears to not be running at all, the problem is that you are accidentally executing it under a version of PHP which is older than the minimum supported PHP version.
In both cases you need to ensure that your site (for WordPress this includes both your public frontend and administrator), as well as any CRON jobs you have, run under a PHP version supported by our software. If you are unsure how to do that, please ask your host. Each host has a slightly different approach to that; we can't possibly know how every host operates.
Our updates always include the minimum PHP version supported by each new version. When our updater code retrieves the update information it compares this to the PHP version it is being executed under (“current PHP version”). If the current PHP version is older than the minimum PHP version supported by our software or newer than the maximum PHP version supported by our software it marks the update as unsuitable. If there is no version listed in the update information which is not marked as unsuitable and at least one of the versions of our software listed in the update information is newer than your current version our updater will report that there is an update available, but you cannot install it because the PHP version is unsupported.
The update information is always cached. In Akeeba Solo it is cached for 6 hours. In Akeeba Backup for WordPress it is cached by WordPress itself, typically for 12 to 72 hours. This caching may lead to some misunderstandings.
It is possible that the update check takes place under one PHP version, but its cached result is displayed under a much newer PHP version. For example, the update check on WordPress may have taken place when WP-CRON last run under PHP 7.2, but viewed in the wp-admin administrator area which currently runs under PHP 8.3. Let's say that the minimum PHP version requirement for the new version of Akeeba Backup is 7.4. You would expect to see that the update is available, and lets you install it. What you see instead is that there is a new version available but your PHP version is not supported. The message is correct. Remember, when the update check took place the “current PHP version” was 7.2 which is lower than the minimum supported PHP version of 7.4.
The solution to this problem is again o ensure that your site (for WordPress this includes both your public frontend and administrator), as well as any CRON jobs you have, run under a PHP version supported by our software. If you are unsure how to do that, please ask your host. Each host has a slightly different approach to that; we can't possibly know how every host operates.
Skipping the PHP version check on update would be dangerous, and would most likely lead to broken sites.
If we assume that you are using the same PHP version everywhere (frontend and admin of your site, and your CRON jobs) and that PHP version is older than the minimum PHP version we support you will at best end up with a non-functional backup system, at worst with a installation which throws PHP errors. The former is worse than the latter, especially on WordPress where updates are installed automatically. You would end up with a non-functional backup system but you'd have absolutely no idea!
Yes, you can still end up with that problem if everything except your backup CRON jobs are using a supported PHP version. However, there's nothing we can do about it. You need to be consistent in your use of PHP versions across all aspects of your site. We can only do so much though; at some point, there's nothing we can objectively do to stop you from shooting your feet.
There are many reasons which come down to the same thing: progress is inevitable.
Since PHP versions have a well-known expiration date, it is to your and your site users' benefit to keep up with newer PHP versions. Do remember that a security breach to your site because you are running old, and known to be insecure software can be a legal liability for you in most jurisdictions. Therefore, software developers have to ensure that you will be able to run their software in newer versions of PHP to protect you and your users.
Supporting older PHP versions means that there comes a point of newer PHP versions cannot be supported. Even WordPress, the champion of supporting old PHP versions, had to abandon this strategy with WordPress 5. There came the point were supporting old PHP versions would mean they would not allow you to upgrade to modern, supported versions of PHP, which would very likely become a legal liability for them.
Older PHP versions do not support modern software environments. For example, talking to modern versions of MariaDB and MySQL requires a modern version of PHP; you can't even connect to MySQL 8 or later from PHP 7.0 or earlier. Older PHP versions won't even compile with newer versions of their dependent libraries; the old libraries have known security issues which can and are used to hack sites and servers. Older PHP versions do not support modern encryption and hashing algorithms which are required for web applications to make use of modern browsers' features such as Web Authentication (WebAuthn / Passkeys), notifications, etc.
Newer PHP versions add new features and gradually break backwards compatibility with older versions for a good reason. A lot of the new features added since PHP 5.3 allow for better code organisation, faster code loading without the scourge of manually including files (and bumping into hard to troubleshoot bugs when the right file wasn't loaded in some weird edge case), reduction of duplicated code, variable type safety, and performance. These features allow developers like us to write more compact code, reduce the probability and severity of bugs, add new features, respond to changes in PHP, CMS, and browser changes far faster, and drastically improve the performance of the software.
In the end of the day it's pretty much the same reason most people would choose a modern vehicle than a 1960s car: better performance, better reliability, better efficiency, better security, and better safety. If you prefer to use something old, you can of course use an old and unsupported version of our software just like you can use an old and unsupported vehicle. You shouldn't expect to get first party support, and you – and everyone else using it, even as a passenger / site visitor – should be aware of the trade-offs.