Support

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 *

WHAT?!

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: https://github.com/WordPress/WordPress/commit/7e9421e4d0fa6d1236a23856626fa1bcb6fb4aa0.

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.