How do you allow plugins to be updated using the GUI without breaking your subversion repository?

3 Views

Development on a WordPress installation is under Subversion version control. We’re not using externals to link in the plugins – the plugins are getting installed / updated by non-developers in charge of content.

This causes issues within the repository, especially for plugins that are already under version control and are just being updated to the latest version, since updating a plugin deletes the directory (including all the .svn folders) and then re-creates it.

Read More

Here’s a typical scenario, that’s causing me no end of grief:

  1. Put an existing WordPress site under version control in a fresh repo. This existing site ALREADY has some plugins. Some of those plugins are out of date
  2. Now, go into the admin and update those plugins

  3. run svn st and you see the following:

    ~ addthis

    ~ google-analytics-for-wordpress

    etc…

The tilde ~ is especially nasty because it means “duh, I dunno wha happuh”, and SVN just cacks. Even copying, deleting, removing, restoring, moving back, attempting to commit – nope.

Many people recommend using svn:externals or manually FTPing the updates, which is all fine and dandy, but I’d just like to be able to use the UI as God intended. From what I can see in core, there’s no hook that can be used to convince WP not to delete the folder, or the .svn folder. Is there something that can be done?

Post Views: 3

Related posts

Leave a Reply

4 comments

  1. Real answer, taking all the above into account:

    Regarding .svn directories: Subversion 1.7 was released a little over a year ago ( http://svn.haxx.se/dev/archive-2011-10/0152.shtml ) and the working copies no longer contain .svn directories in every folder. They contain a single .svn directory in the root, along with fairly substantial performance improvements. Today, SVN is up to version 1.7.7. You should upgrade your svn client to eliminate this as any sort of problem.

    That answers the Original Question, because WP deleting the directories and re-creating them is no longer really an issue. It won’t mess up a Working Copy made by Subversion 1.7 or above. However, it doesn’t answer the larger question of repository management with regards to production deployment and dev/testing environments.

    Basically, how you manage your production machines is up to you. If you actually have a real “production” environment, then you should use a permissions scheme and/or plugins to disable the ability of users to upgrade the system directly. Users can’t change production. That’s sort of the point of calling it “production”. Changes in such a case would be made by devs and rolled through testing and/or QA systems first. If you have such an environment and really need that sort of level of control, then disabling the upgrader entirely would be the preferred way to go.

    Heck, I use just that sort of environment myself, although I control dev, testing, and production all the way through. The whole site is in an SVN repo. Some of it indeed uses externals (I use WP trunk, a few plugins I use as trunk versions), some of it doesn’t and is local to the repo. For me, deploying changes to production means doing an svn up on those boxes, basically. Changes can’t be made directly on those boxes filesystems.

    On the other hand, some sites I run just straight up live, with regular backups. If my personal site is wonky for a bit, then it doesn’t really affect me any. I use the WP updater on those just fine. Now, I don’t run those sites in a repo, I just have regular backups of the whole thing. In point of fact, I use VaultPress on my personal sites, but any method of backup is a good idea. This is a different type of management, one where I don’t need a dev/testing environment.

    WordPress works fine with any sort of system you wish to create around it, but that system is external to WordPress, and how you manage it is a question of not of WP but of how you want to manage it, really.

  2. Not tested yet, but add_filter('upgrader_clear_destination', array(&$this, 'delete_old_plugin'), 10, 4); looks good. You will find it in wp-admin/includes/class-wp-upgrader.php
    Remove the filter before updating your plugins. This could be a bit tricky because you have to search for the correct function name to be remove. Toscho wrote a post about removing anonymous hooks (german).

    But apply_filters('upgrader_pre_install', true, $hook_extra); (same file as above) seems to be the better solution. Hook into ‘upgrader_pre_install’ and save your .svn directory. Also hook into ‘upgrader_post_install’, this hook will be done after the update. After updating the plugin, simply copy back your .svn directory.

  3. If you want to manage your WordPress install through version control, then I don’t see a way how can you do so along with updating the plugins from WordPress admin panel only.

    Ideally it should be like this:

    • Checkout a copy of your repo on local.
    • Update the plugin from WP admin.
    • Test
    • Commit
    • Checkout the latest version on production (checkout meaning deployment of those commits)

    And this works flawlessly with GIT. With SVN, it can be an issue since it has a .svn directory in each directory, but like Otto suggested SVN 1.7 can help you here as there will only be a single .svn directory in the root.