[wp-trac] [WordPress Trac] #33571: Improvements for plugin upgrades when disk space runs out (or other write failure)
noreply at wordpress.org
Thu Aug 27 14:55:53 UTC 2015
#33571: Improvements for plugin upgrades when disk space runs out (or other write
Reporter: DavidAnderson | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Upgrade/Install | Version: trunk
Severity: normal | Keywords:
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-
* 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.
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
Ticket URL: <https://core.trac.wordpress.org/ticket/33571>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac