[wp-trac] [WordPress Trac] #51857: Add rollback for failed plugin/theme updates

[WordPress Trac]

#51857: Add rollback for failed plugin/theme updates
-----------------------------+-----------------------------
 Reporter:  pbiron           |       Owner:  pbiron
     Type:  enhancement      |      Status:  reopened
 Priority:  normal           |   Milestone:  Future Release
Component:  Upgrade/Install  |     Version:
 Severity:  normal           |  Resolution:
 Keywords:  early has-patch  |     Focuses:
-----------------------------+-----------------------------

Comment (by SergeyBiryukov):

 Replying to [comment:56 dd32]:
 > An alternative option would be to flip this around, and not add a
 rollback functionality into it, but rather install into a temporary
 directory first, and then remove existing/rename new into place.
 >
 > (edit: I guess that's kind of how it works now, except the temporary
 install directory is wp-content/upgrade/somethinghere. It's the copy from
 there to the plugins directory that sometimes fails, so avoiding that copy
 by extracting into the plugins directory in the first place and then
 performing a move() would mean far less IO is needed and as a result could
 be faster too)
 >
 > That would result in less downtime of the plugin not existing on the
 site, and also not delete the plugin from the site in the event of a
 failure to create the new files.

 @dd32 When you have a moment, could you take a look at
 [https://github.com/WordPress/wordpress-develop/pull/1492 PR 1492]?

 In this implementation, we've explored the approach you suggested, with a
 notable difference that we chose not to use `wp-content/plugins` as a
 temporary directory, as that might lead to multiple copies of the plugin
 being displayed on the Plugins screen. Even if it's only for a short
 period of time, I think it might still cause confusion if someone tries to
 activate a temporary copy of the plugin.

 We did replace copying with a call to `::move()` though, for better
 perfomance. Most of the time, that should be a simple `rename()` call. If
 the rollback directory is on another filesystem, I guess a `rename()`
 would not work, but in that case the `::move()` method
 [source:tags/5.8/src/wp-admin/includes/class-wp-filesystem-direct.php#L318
 uses copy()/delete() as a fallback], which I think should work :)

 As per the PR description:
 > * When updating a plugin/theme, the old version of the plugin/theme gets
 moved to a `wp-content/upgrade/rollback/plugins/PLUGINNAME` or `wp-
 content/upgrade/rollback/themes/THEMENAME` folder. The reason we chose to
 move instead of zip, is because zipping/unzipping are very resources-
 intensive processes, and would increase the risk on low-end, shared hosts.
 Moving on the other hand is performed instantly and won't be a bottleneck.
 > * If the update fails, then the "backup" we kept in the upgrade/rollback
 folder gets restored to its original location.
 > * If the update succeeds, then the "backup" is deleted.
 > * A new section was added in the site-health screen, to make sure that
 the rollbacks folder is writable.
 >
 > To avoid confusion: The "rollback" folder will NOT be used to "roll-
 back" a plugin to a previous version after an update. This folder will
 simply contain a **transient backup** of the previous version of a
 plugin/theme getting updated, and as soon as the update process finishes,
 the folder will be empty.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/51857#comment:96>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform