Could it be that the web host's PHP_VERSION is incorrect? You are saying this constant is what Akeeba Backup is relying on. I will ask the web host tech support about it.
I can only tell you what we do to report the PHP version and I'm telling you that we just echo PHP's constant which is defined at compile time. This is the PHP version you are actually running.
MultiPHP Manager thinks the "system default PHP version" is PHP 7.1, but of course within the list of domains I see PHP 7.4 is listed for each of them.
Check with the host's tech how the non-default version is applied. It should be a .htaccess directive similar to AddHandler something .php where "something" is a server-specific string (it depends on the server's configuration) which is why I can't tell you how to fix it.
Also note that it's perfectly possible to have a different PHP version in the frontend of your site and its administrator section because the latter is in a different directory (wp-admin). In other words, it's possible that the wp-admin directory is set up to use a different PHP version than the rest of the site. I've seen that too many times.
Besides what I see in Site Health, is there some other way to double check what PHP version Akeeba Backup will think I'm using?
You mean besides Akeeba Backup itself conveying the PHP version reported by PHP's compile-time version constant? :) Yes, of course. Create a file named foobar.php with the following one-line content:
<?php phpinfo();
Place it in your wp-admin folder and then access the /wp-admin/foobar.php URL on your site. You will see the PHP version printed at the top of the page with very large type.
For the "avion" website -- the one where I renamed the wp-content/plugins/akeebabackupwp folder -- by installing anew Akeeba Backup version 7.5.1. I successfully made a backup there. The log file in the new backup also reports PHP version as 7.4.16.
There were two error messages you gave me. I told you how to deal with the second one since it's a fatal error that takes priority. In other words, if it's not fixed first then addressing the other one will do nothing.
So let's go back to the first error message, complaining about a missing class. The class it says it cannot find actually exists in the file wp-content/plugins/akeebabackupwp/wpcli/Command/NamespaceDescription.php. If the file is missing it'd mean that WordPress failed to update Akeeba Backup. If the file does exist then something's wrong. In both cases the first thing I'd try is refresh the installation. Download the Akeeba Backup package from our site, extract it. Upload the extracted akeebabackupwp folder into wp-content/plugins, overwriting the files and folders in the existing akeebabackupwp folder. This way if anything was missing or not fully updated it will be replaced.
I still wonder if Akeeba Backup version 7.5.6 has something about it that makes it cause the WordPress critical error that breaks the website.
No, not at all. It's a maintenance release. Our versions number typically follow the format x.y.z or x.y.z.p. In this format x is the major version, y is the minor version, z is the revision and p is the patch level. Massive changes or changes with a major impact (e.g. changing the JavaScript or CSS framework we use, convert our view templates to Blade etc) cause the major version to increase. Important changes and new features cause the minor version to increase. Maintenance work (bug fixes, cosmetic changes, small additional features in the backup engine) cause the revision to increase. If there's a single bug which causes a revision to fail to install or load on the majority of sites we release a new version increasing the patch level (if there is no patch level noted it's assumed to be 0). That is to say, 7.5.6 only has minor bug fixes compared to 7.5.5.
You can verify this in the changelog:
~ WordPress restoration: Home URL and Site name are now required
~ Converted all tables to InnoDB for better performance
# [HIGH] Cannot take split archive backups under PHP 8
# [LOW] PHP warnings about use of undefined path when WordPress updates itself
# [LOW] Cannot list an open_basedir restriction root
None of these have anything to do with the PHP version detection. In fact, the code about the minimum PHP version, the code about an outdated PHP version and the code of our error handler is common across all of our software, both WordPress and Joomla. If that code was broken then all of our extensions across both CMS would be broken. Trust me when I say that we'd have heard about this within minutes of a release, let alone after a month or more.
Either your PHP version is not what you think it is or Akeeba Backup is half-updated and needs a refresh of its files to work properly.
Nicholas K. Dionysopoulos
Lead Developer and Director
🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!
