[wp-trac] [WordPress Trac] #31138: Backup of a plugin / theme directory.

[WordPress Trac]

#31138: Backup of a plugin / theme directory.
-----------------------------+------------------------------
 Reporter:  aercolino        |       Owner:
     Type:  defect (bug)     |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Upgrade/Install  |     Version:  4.1
 Severity:  normal           |  Resolution:
 Keywords:  has-patch        |     Focuses:
-----------------------------+------------------------------

Comment (by aercolino):

 @dd32,

 > the end result would still be the same, to remove all the existing
 files, and replace it with a new set.
 That is the way, no doubt. The point is that never ever we remove anything
 before making a backup. Or making sure that what we remove is exactly the
 same thing we already have somewhere else, which is what a backup
 guarantees.

 > This has been a problem/concern for Themes for a long time, ...
 With changes to the code of a plugin / theme, the problem of how to make
 them persist after an update is quite different from what I'm discussing
 here and, I might say, much more complex to solve.
 * BUT, if WordPress doesn't automatically make any backup, we can be sure
 that the new plugin / theme version has no way to know if such changes
 were present in the first place.
 * INSTEAD, if WordPress automatically makes a backup, the new version can
 make the UX much much more pleasurable. [[BR]] For example, version 2
 could compute a hash of the backup and compare it to what it should be,
 and if they differ it can take the steps it pleases. It could ask the
 user: "Hey admin, version 2 of Super Fantastic Theme speaking. I noticed
 you made some changes to version 1. If you proceed with the update your
 changes are not lost but you will have to apply them again by yourself.
 You can find your version 1 in the directory ... If you Cancel the update,
 your version 1 will be restored. [Proceed] [Cancel]". [[BR]] Ultimately,
 plugin / theme authors would have all they need to decide how to update.

 > 2. If WordPress 4.2 added some kind of way to have files retained during
 update automatically without the plugin doing anything
 Sorry but I can't understand where is the problem... Here is how the
 update flow looks like after applying my patch.

 1. WordPress 4.2 implements automatic backup of a plugin / theme files.
 (This is my patch.)
 1. Users get notified that WordPress 4.2 has been released and it
 implements automatic backup to improve UX when updating. (This is only
 meant to be a bell-ringer later, when updating plugins / themes.)
 1. The new version of my plugin states that it requires WordPress 4.2. (I
 realize this is not perfect because users could update it before updating
 WordPress, however it does offer another bell-ringer to users.)
 1. Users get notified of the new version and click the ''update now''
 link.
 1. WordPress 4.2 makes a backup of all the files in the directory of my
 plugin, then deletes the directory and puts there all the new files.
 1. The user or WordPress activates my plugin again and version 2
 activation code will run.
 1. It will detect that this is an update and it will find the backup
 WordPress made.
  * It will copy user's files from the backup directory back in the plugin
 directory. [[BR]](This is only my use case. Any plugin / theme author can
 do whatever they see fit.)

 ----

 I don't remember how the ''Requires at least'' feature currently works,
 but I think that that is also quite a key piece of the puzzle. I mean,
 plugin / theme authors are very interested in making the minimum supported
 version of WordPress as low as possible. So it would make a lot of sense
 to strongly (actively?) discourage users from installing / updating to a
 plugin which requires a version greater than what they are using.

 ----

 I looked into how the update works for WordPress core and we already allow
 new code to get executed in place.
 https://github.com/WordPress/WordPress/blob/master/wp-admin/includes
 /class-wp-upgrader.php#L2021-L2033

 At some point I thought that something along those lines could be done for
 plugins / themes, for example by using an `install.php` script (nicely
 symmetrical to `uninstall.php`) and copy / include / execute it in a
 similar fashion, but then I realized that that would entail many changes
 to the current flow, and we'd have to educate about many details.

 I'm now convinced that the most flexible and unobtrusive solution is to
 automatically make a backup of the plugin directory. Notice that it is a
 temporary backup. Some tuning would be required there, but the idea is
 that a scheduled garbage collector (not included in my patch) could get
 rid of expired stuff on a regular basis. Expired backup directories are
 easy to find: they are those without a corresponding (non-expired)
 transient with a name equal to the directory.

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