[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 dd32):

 Ultimately @aercolino, your plugin users are going to have a bad upgrade
 path no matter what WordPress does, or doesn't do.

 1. If WordPress 4.2 added some kind of save files during an update, your
 plugin would need to be updated first to specify what to backup = custom
 files deleted
 2. If WordPress 4.2 added some kind of way to have files retained during
 update automatically without the plugin doing anything (which might I add,
 would be impossible since plugins legitimately remove files during
 updates, ie. 1.1 won't have file.php while 1.0 did) = custom files deleted
 if a user updates the plugin before WordPress (which I should add, should
 be the standard way of updating a site)

 Realistically, all plugins should never store data in it's own folder, and
 should store it in a custom folder in WP_CONTENT_DIR, or if it has to be
 writable by the webserver, possibly a subdirectory of the uploads folder.

 You could add a Upgrade Notice and Changelog specifying that users should
 backup their data or move it to a different location before a plugin
 update, that's your best bet, unfortunately though many users will simply
 update (or it'll happen automatically on some hosts/configurations)
 without ever reading that. I can't think of an easy way to issue an update
 notice that won't cause  file deletion, I think if your repo even only
 contains a readme.txt then the ZIP would still end up overwriting the
 plugin (although that could be worth testing). Unfortunately testing the
 update mechanisms isn't easy, the best way is probably using the 3rd-party
 script that pulls an update from Github.

 ----

 >>This is not a bug. It is a design decision made many years ago.
 >Not because it is an old decision it cannot be a bug in hindsight.

 It can definitely be seen as a bug, or as a feature, depending on how you
 look at it. If I was implementing it from scratch again, I'd probably have
 used something slightly different, but the end result would still be the
 same, to remove all the existing files, and replace it with a new set.
 This has been a problem/concern for Themes for a long time, people will
 edit the CSS/PHP files directly, then update the theme, and be shocked
 their customizations were lost. The proper method in that case is to have
 the modifications in a child theme.

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