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:

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

Now, go into the admin and update those plugins

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?

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 AugerNov 27 '12 at 16:27

5

Have you considered switching to Git and using a .gitignore?
–
toscho♦Nov 27 '12 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 BoynesNov 27 '12 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 AugerNov 27 '12 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.
–
OttoNov 27 '12 at 17:39

4 Answers
4

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.

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 AugerNov 28 '12 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 AugerDec 3 '12 at 17:27

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.

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 AugerNov 27 '12 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.
–
Ralf912Nov 28 '12 at 22:26

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.

@TomAuger So much for being a developer & just saying "doesn't work" instead of actually stating the issue.
–
AshfameNov 27 '12 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.
–
OttoNov 27 '12 at 17:43