Support

Akeeba Backup for WordPress

#35142 – Akeeba backup update to 7.5.6 breaks two websites with critical error

Posted in ‘Akeeba Backup for WordPress’
This is a public ticket. Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.
Tuesday, 27 April 2021 05:52 CDT
mattsson

Update to Akeeba Backup 7.5.6 breaks two WordPress websites at InMotion Hosting with critical error:

There has been a critical error on this website. Please check your site admin email inbox for instructions.

But a similar website at SiteGround accepts the Akeeba Backup without problems.

Two websites at InMotion Hosting but website at SiteGround (SiteTools) doesn't have the problem. I'll describe the problem for the two websites under development at InMotion Hosting (penny.mattsson.pro using Spacious theme and avion.mattsson.pro using Astra theme). For avion.mattsson.pro, I think WordPress was already up to date but a few plugins were out of date, including Akeeba Backup. Right after the Akeeba backup finished, clicking on any other link went to a white screen displaying the critical error.

On penny.mattsson.pro, this same error message appeared after updating Akeeba backup AND a few more plugins.Β  The penny.mattsson.pro site MIGHT have other problems -- the theme won't update, and removing unused plugins seems to never finish, for example.

In both cases, InMotion Hosting tech support identified the problem as being caused by Akeeba Backup plugin. If we renamed the plugin folder over FTP, then we can manage the website again. He reported two error messages shown by Akeeba backup for penny.mattsson.pro (I don't know where he saw the errors, as I think the website was having the critical error at the time)

Error: Callable "Akeeba\\WPCLI\\Command\\NamespaceDescription" does not exist, and cannot be registered as `wp akeeba`.

Akeeba Backup for WordPress requires PHP 7.2.0 or later but your server only has PHP 7.1.33.

At the time "site health" info was showing the PHP version as 7.4.16.

The tech said the server was properly configured.

Since there are a couple ofother errors that I must consistently work around at InMotion Hosting but not at SiteGround, I found a similar WordPress website I'm hosting at SiteGround (teal.elizahost.com using Spacious Pro theme) that needed plugin updates. I updated WordPress and all plugins except for Akeeba Backup then checked over the website. THEN I updated Akeeba Backup and the site was STILL fine.

So the problem seems to only be happening for me at InMotion Hosting websites.

Still, I have a lot of practice and staging websites hosted at InMotion Hosting, with years of successful plugin updates to Akeeba backup, so I hope you can help me to solve this problem.

Sincerely,

Carol Mattsson

Custom Fields

WordPress version (in x.y.z format) 5.7.1
PHP version (in x.y.z format) 7.4.16
Akeeba Backup version (x.y.z format) 7.5.6
Β 
Tuesday, 27 April 2021 07:26 CDT
nicholas

Akeeba Backup for WordPress requires PHP 7.2.0 or later but your server only has PHP 7.1.33.

There's your problem. The version reported is not "detected". We literally just print out PHP's PHP_VERSION constant which is set up when your host compiled their PHP executable. In other words you can be 100% certain that your site actually runs PHP 7.1.33 despite what your hosting control panel reports. Most likely your hosting control panel reports the PHP version the hosting control panel software runs on, not the PHP version your site runs on.

Do note that a single server can have multiple versions of PHP installed. I have a test server with concurrent installation of PHP 5.6, 7.0, 7.1, 7.2, 7.3, 7.4 and 8.0. Of course only one of them can handle a site at any one time. In your case the PHP version handling your site is 7.1.33.

Since the tech didn't catch this obvious problem please ask them explicitly how to set a different PHP version for your site. In most cases you have to either edit your .htaccess file or use a hosting control panel page which does that for you, albeit with a much friendlier user interface. You need to use at least PHP 7.2. However, we strongly recommend PHP 7.4 if supported by all plugins on your site. PHP versions up to and including 7.2 are already End of Life which means they no longer receive security fixes. PHP 7.3 is in security maintenance mode until December 2021 which means it receives no bug fixes except high priority security bug fixes β€” at least for the next 7 months; then it becomes End of Life itself. The only currently active PHP versions are 7.4 and 8.0.



Nicholas K. Dionysopoulos

Lead Developer and Director



πŸ‡¬πŸ‡·Greek: native

πŸ‡¬πŸ‡§English: excellent

πŸ‡«πŸ‡·French: basic



Please keep in mind my timezone and cultural differences when reading my replies. Thank you!



Wednesday, 28 April 2021 19:10 CDT
mattsson

Hi Nicholas,

Did you catch that Site Health for WordPress was reporting the PHP version as 7.4.16?Β  I've used the web hosting control panel to set the PHP version.

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.

Indeed the InMotion Hosting web host does run multiple versions of PHP,Β  I can choose the version I want to use for each domain using their cPanel's "MultiPHP Manager."Β  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.Β  I will ask the web host tech support about this too, as maybe Akeeba Backup is finding the PHP version 7.1 from there.

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?

I've rebuilt the "penny" website from scratch.Β  The original was cloned from a GoDaddy website that reported running PHP 7.2, that might have been part of the problem.Β  There I installed Akeeba Backup version 7.5.1 (a version from January). At that website, the Akeeba Backup log reports PHP version 7.4.16.

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.

I'm used to seeing Akeeba Backup's message in a WordPress website where it's installed, complaining about the PHP version being inadequate.Β  But that case doesn't cause the "critical error" I saw the other day.Β  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.

Β  * * *

To summarize, if I can't believe the PHP version reported by Site Health and the Akeeba Backup log itself, is there some other way I can verify the PHP version according to what Akeeba Backup software itself will respond to?Β  Β And why does the older Akeeba Backup version 7.5.1 work OK with this web hosting setup but gives "critical error" if I upgrade to Akeeba Backup version 7.5.6?

Β 
Thursday, 29 April 2021 01:08 CDT
nicholas

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



Please keep in mind my timezone and cultural differences when reading my replies. Thank you!



Thursday, 29 April 2021 01:17 CDT
nicholas

I accidentally sent you a wrong message meant for a different ticket. I deleted it from the public ticket but you still received an email about it. Please ignore that. Sorry.



Nicholas K. Dionysopoulos

Lead Developer and Director



πŸ‡¬πŸ‡·Greek: native

πŸ‡¬πŸ‡§English: excellent

πŸ‡«πŸ‡·French: basic



Please keep in mind my timezone and cultural differences when reading my replies. Thank you!



Thursday, 29 April 2021 11:19 CDT
mattsson

Thank you Nicholas for your thorough reply. I see how I can check my PHP version and whether there might have been a partial install of Akeeba Backup on the "penny" site. I'll check out these two things and report back within the next few days.

(I'm eager to know the result, but I must pause my investigation in order to keep up with other projects, now that I have the temporary workaround of a slightly older version of Akeeba Backup for the two websites.)

No problem about the stray message.

Thanks again, Nicholas,

Carol Mattsson

Β 
Friday, 30 April 2021 01:46 CDT
nicholas

No problem! Your ticket will be on hold for 30 days waiting for your reply. If there's no reply in these 30 days it will be closed but you will always be able to open a new ticket and reference this one to give me context.



Nicholas K. Dionysopoulos

Lead Developer and Director



πŸ‡¬πŸ‡·Greek: native

πŸ‡¬πŸ‡§English: excellent

πŸ‡«πŸ‡·French: basic



Please keep in mind my timezone and cultural differences when reading my replies. Thank you!



Tuesday, 25 May 2021 02:57 CDT
mattsson

Hello Nicholas,

Thanks again for all your troubleshooting tips. I think I've solved the problem -- Akeeba Backup updates just fine on both websites. The fix was to edit the .htaccess files of both websites in the same way, to comment out two lines from each.

DETAILS:

I created your foobar.php file with the phpinfo call and ran it from both document root and the wp-admin folders. Every time it reported PHP Version 7.4.16.

Then I looked for an AddHandler directive in .htaccess, related to PHP version. I saw none, but I did see ...

Below both <IfModule php7_module> and <IfModule lsapi_module> I see:

php_value session.save_path "/var/cpanel/php/sessions/ea-php71"

These values from the cPanel MultiPHP INI Editor. I asked InMotion Hosting tech support what they were, and the best answer I could get is, try commenting them out.

So I did that. I also commented out a similar line in the php.ini file I found in the same folder (document root)

After uploading the changed .htaccess and php.ini files to the server, and making SURE I had made an Akeeba Backup, I tried updating Akeeba via the WordPess Dashboard's Updates page. The update went fine. YAY! Both websites seem stable.

Two other findings, which may or may not be meaningful to you:

1) The default PHP version on the server is version 7.1. InMotion Hosting tech support says I can't change that. But as we have found, the PHP versions set by MultiPHP manager cPanel app, for each individual domain name or subdomain name, appear to be the versions of PHP that are actually used for each individual website.

2) About the missing file, indicating the incomplete update of Akeeba Backup, yes that file was missing:

wp-content/plugins/akeebabackupwp/wpcli/Command/NamespaceDescription.php

However that file was missing in clone #2 (penny.mattsson.pro), the one made from the Akeeba Backup archive obtained from GoDaddy. I can't remember if I ran the MultiPHP INI Editor before or after I tried to update clone #2. But the website back end was throwing other update errors and generally unstable, so I abandoned it and rebuilt the current website version from scratch (penny.eliza.pro).

I also found this variable setting in clone #2's wp-config.php: FS_METHOD was set to direct. I'd not seen this setting in a wp-config.php file before. A thread at wordpress.stackexchange.com recommended only changing FS_METHOD if you are experiencing update problems. Maybe it was necessary for GoDaddy but was the wrong setting for my InMotion Hosting.

Thanks again for your advice Nicholas. I hope this thread helps others to fix their website if Akeeba Backup complains about a PHP version that doesn't seem to match the PHP version you expect the website to be running. Especially if you recently used cPanel's MultiPHP INI Editor.

One more thing, I didn't actually go back, and UNcomment out the seemingly troublesome lines and try the update again.Β  To see if that REALLY was the cause of the problem.

Sincerely,
Carol Mattsson

Β 
Tuesday, 25 May 2021 04:47 CDT
nicholas

What you shared here corroborates what I'd written in my first two replies a month ago.

The default PHP version is 7.1. PHP 7.4 is what cPanel is using, not what your site is using. You needed to use the MultiPHP manager to apply a different PHP version. Note that I'd told you that in my first reply, a month ago.

The session.save_path tells PHP where to save the temporary files for the PHP session, overriding the global defaults. I suspect that the folder referenced there is wrong and PHP can't write to it. Removing these lines tells PHP to fall back to the system configuration which must be correct. This is why they told you to remove them. Note that if you are moving a site you can always tell the restoration script to reset your .htaccess to the default settings and remove any .user.ini and php.ini files  in the Site Setup page. Therefore any server-specific settings from your old host will not be removed and not cause any problems.

The missing file is something that is normally included with our software. The fact that it is missing is not a bug in our software. Something outside our software or someone deleted this file. This is why you were getting the PHP warning message. Reinstalling Akeeba Backup without uninstalling it will fix it. This is what I told you in my second reply to you a month ago.

The FS_METHOD is an architecturally incorrect way to address bad hosting configurations within WordPress. Joomla used to do the same but this feature was removed in Joomla 4.0, scheduled for release this Fall. It doesn't matter whether you change it or not; InMotion's servers are correctly configured so WordPress will always use the direct method there. Removing that line has no effect on your site. It's a red herring.



Nicholas K. Dionysopoulos

Lead Developer and Director



πŸ‡¬πŸ‡·Greek: native

πŸ‡¬πŸ‡§English: excellent

πŸ‡«πŸ‡·French: basic



Please keep in mind my timezone and cultural differences when reading my replies. Thank you!



Sunday, 06 June 2021 02:45 CDT
mattsson

Thanks for your clarifications Nicholas.

All continues to work well with the Akeeba Backup for WordPress that I have installed on my WordPress websites.

Today I checked with InMotion Hosting about that session.save_path folder. The rep. said indeed, that default session.save_path refers to a folder that doesn't exist on the server. He also filed a support ticket to look into the problem further.

I found one more website on InMotion that has in its .htaccess file, that same session.save_path. I'd not updated this website since last September. I updated its plugins, themes and WP version tonight, including to the latest Akeeba Backup, without incident. This time I did not comment out the session.save_path lines from the .htaccess file.

Sooooo - I can't explain why this 3rd website doesn't exhibit the same problem as the others. Something else may have been wrong at InMotion Hosting when the problem first showed up for the first two websites, or IMH tech support may have changed something regards the support ticket, but I don't see any messages from them about it.

I'm ready to close this ticket, but I'll leave it open in case you have more to say about it.

Thanks again for your help Nicholas.

Sincerely,
Carol Mattsson

Β 
Monday, 07 June 2021 00:54 CDT
nicholas

Is it possible that the two sites were hosted on different servers with possibly different setups? Another difference is that the .htaccess PHP directives only apply to PHP running as an Apache module but not to PHP running as a CGI / FastCGI process. So it is perfectly possible to see different behaviours even on the same server when using its default PHP version (typically implemented as an Apache module) and any other PHP version available on the server.



Nicholas K. Dionysopoulos

Lead Developer and Director



πŸ‡¬πŸ‡·Greek: native

πŸ‡¬πŸ‡§English: excellent

πŸ‡«πŸ‡·French: basic



Please keep in mind my timezone and cultural differences when reading my replies. Thank you!



Tuesday, 08 June 2021 03:00 CDT
mattsson

Hi Nicholas,

I think it's likely that all three websites I've mentioned, are all running on the same server, since they are all hosted at my one account there at InMotion hosting.

InMotion Hosting tech support support replied but offered no new information.

So, I'm sorry, I just don't have any more information to give you about what might have caused Akeeba Backup's update to fail at two websites but to work just fine at a third.Β  I'm learning towards something else going wrong at the server during the initial failure.

I sure appreciate the level of detail and concern you gave to my problem report.Β  Thank you again for looking into the problem with me.

I think we can close this ticket now.

Sincerely,

Carol Mattsson

Β 
This ticket is closed, therefore read-only. You can no longer reply to it. If you need to provide more information, please open a new ticket and mention this ticket's number.

Support Information

Working hours: Typically we work Monday to Friday, 9am to 7pm Cyprus timezone (EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets, but we cannot respond to them, outside of our working hours.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!