Support

Akeeba Backup for WordPress

#29050 Update Errors

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.

Environment Information

WordPress version
n/a
PHP version
n/a
Akeeba Backup version
n/a

westiefan
Hi I am getting the following error when updating to Akeeba Backup for WP when I click the update button: "JSON.parse: unexpected non-digit at line 1 column 2 of the JSON data".

I have read your response regarding the restore.php file, and I have manually uploaded all of the files as suggested to a previous user, but now when we access the Akeeba backup dashboard page I get a blank screen (see screenshot attached).

This has happend a few times recently, when updating the Akkeba backup for WP Plugin, and where it is not an issue for me to manually update the plugin (though it did NOT work this time!!!), it is not possible for my clients to do this themselves, so a fai;lure to update is really not helpful.

Please advise how I can fix this as we need to take a backup of the site before updating the WP core (that is another issue that I will raise a separate ticket for, as AB for WP does not automatically generate a backup as it does in Joomla!!)

Thank you.

John R

westiefan
Quick update: Re-installing manually a second time resolved the blank screen issue, but the problem remains that my clients are not technical users, and are not able to carry out manual updates themnselves directly, so we really need this issue to be resolved so that the errors do not occur in the first place.

On another related note, I am surprised that you have released a beta version for use on production sites, any reason why it could not have waited for the stable version, and could it be that the issue is only because it is a beta release?

John R.

dlb
John,

Any time there is a change to the restore.php file, a manual update is probably going to be required. Most servers don't like it when the currently executing file is changed by the update. And we've had several changes to that file over the last several versions. It is our goal to make it work through the built in update system, but there are circumstances that we just can't work around.

The beta is not intended for live systems. My WordPress system clearly tells me that there is a new version, but it does not meet my configured minimum stability level (stable). The Minimum stability level is set in System Configuration (at the bottom) on the Update tab.


Dale L. Brackin
Support Specialist


us.gifEnglish: native


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


????
My time zone is EST (UTC -5) (click here to see my current time in Philadelphia, PA)

nicholas
Akeeba Staff
Manager
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.

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!

westiefan
Hi Nicholas,

Thank you for your insights, much appreciated as always.

Ref the beta versions, I thought our settings already were set to only notify stable updates, but hey ho, I will check again (particularly for unsupported sites etc).

For the most part my issue is not for sites where the clients have a support contract with us, as I am ok with a manual update if necessary. The problem is the screeming phone calls that I get from our unsupported clients when something like this goes wrong (and yes I do use the call to try and persuade them onto a support contract etc, but usually they are just not receptive at the time!!), and they are unable to manually update etc themselves.

As this is a known problem, would it be feasible to do some kind of check on the version of the restore.php file at the start of the process to determine if it is likely to cause an issue during the update, and if so stop the update process before it gets to the error stage with a message recommending a manual update (e.g. contact your developer for assistance etc)?

They could then have an option to abort the update and contact their support, or to continue and manually update themselves (if they are able to do so). The big problem for most of our clients without a support contract is that they panic when something goes wrong and have no way to fix it, whereas if they were notified before the error occurred that there is a potential problem, then at least they could avoid the white screen of death etc and contact their support service etc.

Regards

John R.

nicholas
Akeeba Staff
Manager
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?

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!

westiefan
Hi Nicholas,

Thank you for your insight, as always it is much appreciated.

In this instance I was relying on my developers description of what the error message was, so I did not see the error first hand, and I have subsequently discovered that the manual update I di to fix the issue was on our development server, so effectively I updated the wrong site, so sorry for any confusion here (this could also explain the version differences etc!!) I subsequently manually updated the production server version and that did fix the issue.

However, just for the sake of clarity and notwithstanding my error in manually updating the wrong site, we have had a similar issue with 3 sites recently when updating, but these were updates from version 2.4.0 to 2.4.2.

I will close this ticket now, as the issue is resolved, and your explaination is sufficient for my greater understanding of the issue.

Thank you for your support as always.

Regards

John R.

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!

Summer vacations: Our support will be closed for replies and new tickets from August 6th to August 21st, 2022 due to summer vacations.