Improvements for plugin upgrades when disk space runs out (or other write failure)

[DavidAnderson]

Problem: here's a support issue I see all the time:

• User sees a plugin update available, and attempts to update.
• The user runs out of disk space (or hosting account quota) half-way though, causing the recursive copy (of the unzipped new plugin into wp-content/plugins/(slug) to fail half-way through...
• ... leaving a directory in wp-content/plugins/(slug) that's only half-populated
• If the file with the plugin header was not one of the files that got copied in (i.e. the abort happens before reaching that file), then the plugin no longer shows in the "Plugins" page in the dashboard.
• Problem: user can't de-install the plugin from their dashboard - but attempts to re-install also fail, as the directory wp-content/plugins/(slug) already exists, which WP will complain about.

Unless the user has a high level of skills, at this point he is stumped, and raises a support request - usually with the plugin supplier.

I'm not sure of the exact conditions for this, as I can see in wp-admin/includes/class-wp-upgrader.php that the destination is cleared first, which in theory should create enough space for copying over the new version. However, the new version could be bigger than the old. I've also seen this inconsistent state left when the copy fails for no obvious cause (succeeds on a second attempt, after clearing out the inconsistent state).

To be clear: the real problem is that the update process is not sufficiently atomic. It's too easy for the filesystem to be left in an inconsistent state where the user can neither remove, nor re-install, their plugin without resorting to either FTP or expert skills (e.g. a file manager plugin). Basically, each time we make a new release of UpdraftPlus ( ​https://wordpress.org/plugins/updraftplus, 500,000 installed users ), I estimate we're likely to handle this support request half-a-dozen times. Multiply that by all the plugin downloads in the WP directory, and all the releases made in a year, and you can get a good picture of how many man-hours could be saved by finding a resolution for this.

Possible solutions?

a) One cunning/quick work-around would be if the code that copies the new plugin in could always attempt to *begin* with the file that has the plugin header. This way, it maximises the chances of that file being copied before any abort, meaning that the user will be able to see, and delete, the plugin from their 'Plugins' page, should an abort happen.

b) Instead of copying directly into wp-content/plugins/(slug), do something more atomic, e.g. use a temporary name - e.g. wp-content/plugins/.(slug).(random-or-special-string), and rename when done. The dashboard "Plugins" page could also be trained to recognise this pattern, so that if any such exist, it will hide the "Activate" link, and only allow the user to delete (so that they can fix their problem and re-install the plugin).

Thoughts? I'd love to not have to see this support request so many times

#25576 is sort-of related, in that it deals with checking disk space for core upgrades; but in my anecdotal view, I see the issue more times related to web hosting account quota, which there's no easy way to know from PHP, rather than disk space which can be easily checked with disk_free_space().

[DavidAnderson]

Just to confirm - "here's a support issue I see all the time" is still the case.

[wseltzer]

I am experiencing this problem with Updraft Plus plugin updates on my site hosted on 1and1.com.

[DavidAnderson]

I thought I'd have a look at the JetPack forums, since JetPack is another big plugin, to see if they have this problem, of plugin updates being incomplete and leaving the plugin in a state that's not repairable without expert skills. I found 3 pretty much instantly:

​https://wordpress.org/support/topic/cant-update-jetpack-plugin?replies=14
​https://wordpress.org/support/topic/jetpack-update-crashed-site?replies=9
​https://wordpress.org/support/topic/failed-jetpack-update?replies=3

[DavidAnderson]

The issue remains unchanged, and remains a significant pain point for WordPress users. It is clearly described and causes plenty of real-world trouble.

Because plugin/theme updates as carried out by WP core aren't very atomic (e.g. they don't just move a fully unpacked directory into place), but involve copying files one by one, it's common enough for the operation to time out with the plugin half-copied.

This auto-closing operation seems like a case of a "solution" that is directed at the symptoms of the problem ("there are too many tickets open in Trac") rather than aimed at the problem itself ("tickets opened in Trac aren't processed in a timely fashion"). Does nothing for the root causes, but hides the consequences of those root causes, at the expense of demotivating people from reporting valid issues.

[francina]

Replying to DavidAnderson:

Problem: here's a support issue I see all the time:

Hi @DavidAnderson
I am going through some issues related to the upgrade/install component. Can you confirm this issue is still relevant?
In the past five years, the hosting landscape has changed in terms of resources made available to users (not all the hosts, of course!) but if you - or anyone else - has noticed such issues, let's continue the conversation and hopefully start working on a patch.

Thank you

[DavidAnderson]

Yes, this issue is still there and relevant, and still causes support requests often.
In my view the proposed solution in this issue - performing the final step of a plugin install update atomically by using a rename() is a much better solution than what has been proposed on make.wordpress.org of roll-backs for partial installs. The idea of rolling-back is a heavyweight band-aid for the lack of atomicity. The solution to the root problem is to implement the atomicity.