Support

Hello John,

I would like to offer some further insight.

Since the updater code is built into Akeeba Backup for WordPress we cannot possibly fix the old, affected versions of Akeeba Backup for WordPress automatically. If you have one of these versions you need to manually update.

The only thing we can do is apply automated testing to make sure this doesn't happen again. The test cases failed to warn us twice and we amended them twice. However, I was not satisfied with that. Right after version 2.4.0 I took the time to rewrite the tests of the updater to include all the known failure modes and several hypothetical ones, including the ones which are acceptable / excepted. We believe that this should be enough to prevent any updater woes in the future. This is how building anything works: you try your best, you fail, you learn from your failures, you do better and you figure out how to not fail the same way again.

The typical way the manual update would fail is if you don't copy all of the files, i.e. your FTP program drops the ball. We'd much rather that WordPress would let you install updates through the Plugins page, just like installing a new plugin (or just like the way Joomla! lets you do it) but for some reason they've decided that plugin updates are either automatic (if everything goes fine) or full on manual FTP upload.

Another reason why you might think the update fails is that there's a code cache on your server, such as Zend OPcache (built into PHP 5.4 and later, enabled by default since PHP 5.6), which still "sees" parts of the old code. Clear the code cache or ask your host to not enable it without asking you. For what it's worth, our automated updater knows about that and cleans code caches. That's why you probably never stumbled on that issue before: we were doing some magic behind the scenes to prevent it.

Now, about the beta version. You might wonder, why do we have a beta version on the download page instead of the stable. Here's the chicken and egg problem. If we don't, nobody downloads the beta, nobody reports bugs and the bugs end up in the stable version. This creates a long term issue where we end up doing multiple releases in a short period of time to address these bugs. This is stressful for us and frustrating for our users. Having the betas on the download page fixes that problem and lends to more stable software down the line. Many people want to help test the betas, very few -if any- know where to download them unless we put them right in front of them.

If you don't want to download the beta you can always download the stable version. If you cannot find it please let me know what you tried so we can improve the discoverability of other versions on our site.

The problem with the updater is that, essentially, restore.php spoke one language and the update JavaScript spoke another. In more technical terms, the encryption algorithm supported by restore.php was updated to be more secure but the update JavaScript was not updated correctly.

You suggest that the update JavaScript checks if restore.php speaks the same language and, if not, cancel the update. This is precisely what it's doing right now. However, from where that JavaScript is standing, it cannot know if the problem is with restore.php, a browser plugin (ad blockers do all sorts of weird things, for example), an antivirus / Internet security application on your machine, your ISP meddling with your traffic (yes, many ISPs do man-in-the-middle attacks to inject ads, notices and whatnot), a firewall / WAF on your web server's end, a PHP issue etc. In other words it cannot know if there is a temporary or permanent issue. So all it can do is say, sorry, I can't run the update because there's an error. It doesn't tell you what error exactly because it cannot know.

As I already told you, the white page does not happen in this case. The white page will only happen if there is some third party issue. Typically it's either a file not copied or a code cache issue. We try really hard to prevent a timeout issue which would lead to a hard crash of PHP and files not being copied, but that's not always feasible and depends on your host. We do try to clear the code caches, as long as the host has not blocked that feature.

Now, based on what you've said so far your issue looks like a code cache acting up WITHOUT the host giving us the option to reset it. I would also venture a guess that you had version 2.4.1 installed which is not affected by the update issue since, well, updates do seem to initiate. Why does the manual update fix your issue? I would assume that's because the filesystem cache gets wiped around that time, forcing the code cache to see the new files, fixing the "old code mixed with new code in PHP code cache memory" issue. Again, maybe ask your host to disable the code cache since you're talking about sites which clearly are not meant to get any IT support, i.e. the client will have zero clue how to reset a code cache after updating any kind of code on their site?