[wp-trac] [WordPress Trac] #33571: Improvements for plugin upgrades when disk space runs out (or other write failure)

[WordPress Trac]

#33571: Improvements for plugin upgrades when disk space runs out (or other write
failure)
-----------------------------+-----------------------------
 Reporter:  DavidAnderson    |      Owner:
     Type:  defect (bug)     |     Status:  new
 Priority:  normal           |  Milestone:  Awaiting Review
Component:  Upgrade/Install  |    Version:  trunk
 Severity:  normal           |   Keywords:
  Focuses:                   |
-----------------------------+-----------------------------
 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().

--
Ticket URL: <https://core.trac.wordpress.org/ticket/33571>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform