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

WordPress Trac noreply at wordpress.org
Mon Jan 26 15:23:50 UTC 2015


#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           |   Keywords:
  Focuses:                   |
-----------------------------+-----------------------------
 Original Summary: Backup of a plugin / theme directory.

 A [https://wordpress.org/plugins/enzymes/ plugin] of mine allows users to
 add custom files to the plugin directory. I am almost ready with my
 ''shining'' new version BUT I cannot let users update with the magnificent
 '''update now''' link. Let me spend a couple of words of appreciation to
 those who made that possible. I LOVE IT. Easily the best feature of the
 last years, together with the same functionality for all the blog update.
 wow.

 I've looked around but I couldn't see any right way to allow my users to
 effortlessly migrate their stuff. In fact I looked into the code and saw
 that the previous version of a package is implacably deleted.

 I have developed a patch for it (against release 4.1). It's quite simple.
 From the `WP_Upgrader::install_package` method, before actually deleting
 the `$remote_destination`, it is backed up. If that completed
 successfully, then a transient is set to store backup metadata. Later a
 pair of functions (`backup_prefix` and `get_transients_like`) allow plugin
 / theme developers to get to all available backups of their package.

 {{{
 /**
  * Get the prefix of the backup name, compatible with transient names.
  *
  * The backup name is used for both a transient (which stores backup
 metadata) and a temporary directory (which
  * stores backup files and directories).
  *
  * Plugin/theme names get truncated after 21 characters and it's possible
 (but quite improbable) that two different
  * packages have exactly the same first 21 characters. In such a case
 there would be a prefix clash. However, to
  * tell them apart, you can check the original plugin/theme directory name
 which is stored into the transient.
  *
  * Notice that many backups can potentially exist for each plugin/theme at
 the same time. The number of backups is at
  * most the number of times the user updated to the latest version, which
 can occur many times in a row against one
  * new version (due to user's retries) or many successive versions (due to
 frequent releases).
  *
  * Example for copying back in place user's customizations.
  * <code>
  * $plugin_dir = dirname(__FILE__);
  * $prefix = backup_prefix($plugin_dir, 'plugin');
  * $backups = get_transients_like("%$prefix%");
  * if (count($backups)) {
  *   $last = array_pop($backups);
  *   copy_dir($last['backup_dir'] . '/custom_files', $plugin_dir .
 '/custom_files');
  * }
  * </code>
  *
  * @param string $package_dir Plugin/theme directory.
  * @param string $type        Either 'plugin' or 'theme'.
  *
  * @return string The prefix.
  */
 function backup_prefix( $package_dir, $type ) {
 }}}

 * Please review everything.
 * Do I need to add some tests?

 Will you add this patch please? I think it will be useful to everyone, not
 only to plugin / theme developers but most importantly to users, which
 will get this added protection for their custom files.

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


More information about the wp-trac mailing list