[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