6

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.

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?

Improve this question
11
  • Tried the following: copied each of the plugins to pluginname_BAK, then ran rm -r pluginname and then svn rm pluginname. To my utter surprise, when I tried to commit I then got svn:/trunk/wp-content/plugins/pluginname is out of date. SVN hell.
    – Tom Auger
    Nov 27, 2012 at 16:27
  • 5
    Have you considered switching to Git and using a .gitignore?
    – fuxia ♦
    Nov 27, 2012 at 17:06
  • I agree with @toscho, this is a great reason to switch to Git. Although, I don't ignore the plugins, I update them using the GUI in a development environment, and then push the changes to my production environment. It's a great workflow and it allows one to easily identify changes, review plugin changes for potential vulnerabilities or incompatibilities, and it allows for an easy "undo" if something breaks.
    – Matthew Boynes
    Nov 27, 2012 at 17:18
  • I should probably check out Git eventually, but it's avoiding the question regarding SVN, which is what this project is on and I can't change that right now. Now how is .gitignore different from svn:ignore? Are you suggesting I put an ignore on my plugins dir? That would be fine, but then I have to upgrade the plugins again on the PROD environment, which could lead to more outage time than I'd like, since if there are any dependencies on the plugins, those would potentially be broken until the update were finished.
    – Tom Auger
    Nov 27, 2012 at 17:27
  • git's ignore is no different than svn's ignore, so if one isn't a solution for you, then switching to git isn't going to help either. Bottom line is that either you version-control the plugins, or you don't. If you version control them, then you have to disable the built-in-upgrade methods. If you don't version-control them, then you can use the built-in upgrader, but you may have to do it on multiple hosts if you have your repo exported to more than one of them.
    – Otto
    Nov 27, 2012 at 17:39

4 Answers 4

Reset to default
7

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.

Improve this answer
2
  • Hey @Otto, thanks for the detailed writeup. I'm in the unfortunate situation of having inherited a Linux server without a lot of knowledge about server administration - this explains my out of date Subversion (and probably a host of other things). I'll read the literature and figure out how to upgrade it, right soon! I think it might be interesting to look into writing a plugin that allows tighter integration of the WP auto-updater and various version control systems, such that the updater was a notifier, and the actual update happens through the VC system. Maybe someday I'll have the time!
    – Tom Auger
    Nov 28, 2012 at 14:19
  • Thanks Otto! I've accepted this answer as the most complete. The bounty got mistakenly awarded to the wrong answer (and an incomplete one at that), and there's no way to undo it. Should make that other user happy though - I daresay you hardly need the additional rep.
    – Tom Auger
    Dec 3, 2012 at 17:27
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.

Improve this answer
3
  • that's an interesting approach. sounds like a heck of a lot of custom work - basically writing a plugin to allow you to update other plugins. I wonder whether this is the basic premise behind how svn-auto-upgrade plugin is supposed to work. Sad thing is, I had that plugin installed and it still didn't do the trick...
    – Tom Auger
    Nov 27, 2012 at 17:29
  • 1
    @TomAuger I have now downloaded and inspect the plugin code. And it does exactly what I wrote in my answer. But it need the ability to execute shell_exec(). I think shell_exec() is deactivated on your server (security) and this is the reason why the plugin does not work properly. You can try to comment out the parts with shell_exec() and the svn-commands and do the svn-commands by hand.
    – Ralf912
    Nov 28, 2012 at 22:26
  • Excellent suggestion, Ralf! I wonder whether the filesystem API couldn't handle some of the things shell_exec() was attempting to accomplish...
    – Tom Auger
    Nov 29, 2012 at 14:38
1
+100

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.

Improve this answer
11
  • Yeah, that totally doesn't work. It would be nice. But it doesn't work like that.
    – Tom Auger
    Nov 27, 2012 at 16:09
  • @TomAuger I work with the above mentioned process all the time and it WORKS!
    – Ashfame
    Nov 27, 2012 at 16:11
  • I guess it works for you, but anyway.
    – Tom Auger
    Nov 27, 2012 at 16:15
  • @TomAuger So much for being a developer & just saying "doesn't work" instead of actually stating the issue.
    – Ashfame
    Nov 27, 2012 at 16:31
  • 2
    Tom: If you're using SVN 1.7 and up, there is no .svn directory in each folder anymore, just one in the root of the working copy. His process works fine for that case, because there is no .svn directory to be deleted by WP and to hork up the working copy. Try upgrading your SVN client. The 1.7 client works fine with older 1.6 servers too, so no worries there.
    – Otto
    Nov 27, 2012 at 17:43
0

Looks like a plugin was created to help with just this.

http://plugins.svn.wordpress.org/svn-auto-upgrade/trunk/

Or, just type "SVN Auto Upgrade" into the Plugin browser in your WP back-end.

Improve this answer
1
  • Nope, maybe that worked before, but it ain't working now. I'll update my question, hopefully get some eyes on it.
    – Tom Auger
    Nov 27, 2012 at 16:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.