Akeeba Backup for WordPress

#39591 Latest Wordpress Akeeba update deleting all configurations

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
PHP version
Akeeba Backup version

Latest post by nicholas on Friday, 06 October 2023 06:48 CDT

[email protected]

EXTREMELY IMPORTANT: Please attach a ZIP file containing your Akeeba Backup log file in order for us to help you with any backup or restoration issue. If the file is over 10MiB, please upload it on your server and post a link to it.

It seems you're already aware, but the 6.3 version of WordPress is a complete disaster, causing all plugin configurations to be lost and also not deleting the update-temp-folder content in many cases, blowing out disk storage.

200 sites to manually reconfigure now!!

Akeeba Staff

I am painfully aware, as I was already writing a 5000+ word article about it — it takes that much to explain WTF is going on.

I can also tell you why that happens. As you said, it's something WordPress 6.3 introduced and BY GOLLY is it a stupid idea if you ever saw one!

In the past, WordPress would install plugin updates using this silly method:

  • Download the new version
  • Extract it in a temporary directory
  • Check that the minimum PHP and supported WordPress version are compatible with your site
  • Delete the installed plugin's folder
  • Move the temporary directory (new plugin version) into the old (and now deleted) plugin version's directory.

Plugin developers like us could write a hook handler for the upgrader_package_options filter and tell WordPress to not delete the plugin's folder. So, yeah, okay, WordPress would do stupid be default, by we were able to tell it not to be stupid all the same.

WordPress 6.3 introduced a new feature which ostensibly takes a backup of the plugin's folder, and restores it if the update fails. However, that's not what it does (BTW, the actual truth is shown in the commit log, but not in the release notes and announcement which everyone, including us developers, get to read). What it actually does is this:

  • Download the new version.
  • Extract it in a temporary directory.
  • Check that the minimum PHP and supported WordPress version are compatible with your site.
  • Move the installed plugin's folder into a temporary backup folder.
  • Move the temporary directory (new plugin version) into the old (and now deleted) plugin version's directory.
  • Delete the previously installed plugin version's temporary backup folder.

* record scratch *


This is not a plugin backup.

This is… automated data loss!

It ultimately deletes the plugin's folder upon successful update. This means that any backup archive stored under the plugin's folder is lost, and any profile configuration is also lost because the profile settings encryption key is deleted.

To make it worse, this new “feature” DOES NOT respect the previously available clear_destination flag in the aforementioned filter hook. Nope! It requires developers to set $options['hook_extra']['temp_backup'] = false. A new thing nobody knew before WordPress 6.3 was released.

In other words, if you had released software in the 15 years between WordPress 3.5 and 6.2 which was telling WordPress “please DO NOT delete my plugin's folder” WordPress will go “LOL, sucks to be you” and delete it anyway as of version 6.3. Whelp!

Even if someone somehow caught that when it was committed in May, they could not know how to address it as it was not documented. If they somehow did bump into the commit, and realised what it really does, and found out how to prevent it from doing what it's doing by running the entire thing through a debugger, they had 3 months to publish a new version. Even in this case, if their users did not update to that version before WordPress 6.3 is released —which is around 40% of active users, per our usage statistics— they would still get their installation destroyed upon upgrade of the plugin after installing WordPress 6.3. So, what was (the guy who committed this code) expected here? That plugin developers can go back in time? Or did he not give a damn? I bet on the latter. He's on Yoast's payroll. Yoast does not store anything in the filesystem. Why would he care if it does not affect the plugin of his employer? Not to mention that there are very few plugins which, like ours, store data inside the plugin's folder. They are a non-zero quantity, or WordPress would never offer a way to prevent it from deleting the plugin's folder. So, not to put too fine a point on it, Sergey just didn't care. And, somehow, this… thing was neither a release blocker nor worthy of a special mention in the release note, despite it being quite the major caveat emptor.

I am in shock and disbelief.

I legitimately thought I must've done something wrong. I could not fathom that WordPress, despite its many flaws, would do something that stupid! And yet, it does. Here's the smoking gun:

Of course, we can no longer publish updates on the same update channel. No matter what we do, it would result in y'all losing your backup profiles and possibly your backup archives. We cannot accept that. Therefore the next update will be a manual update, it will involve a migration, and it will have a new update channel — everything we need to let WordPress completely remove the plugin's folder every time you update it.

At least, now we know a couple of truths about WordPress:

  • They think that deleting plugins before updating them is the only way to do plugin updates. Apparently the existence of post-upgrade scripts in literally everything computer related the last 50 years has escaped them.
  • They do and will release backwards incompatible code without documenting the behavior change, despite their propaganda to the contrary.

Noted, and adapting our code and testing to account for this.

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!

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

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!