I use Subversion with my websites. Up until now, this has meant creating a new repo for each of my sites. However, this is wholly inefficient as it means me lugging around the whole WordPress source for each of the sites. It also has meant that I have to copy plugins between repos and thus duplicate the code each time.

So what I wanted to do was have a repo which only really contained my theme file (and possibly other site-specific directories such as site-specific plugins). This would then have a link to the tagged WordPress repository for the WordPress version I would be building against and a link to my other shared plugin repos, so that in order to release or deploy for testing I would only have to do a svn checkout svn://path/to/site/repo and it would download the whole WordPress repo, all my plugins and all the site-specific stuff too.

Is there any way to do this? Or is this a bad idea? Is there an easier/better way to do this at all? How do others do it?

  • Since the WordPress core files and the plug-ins I generally use end up getting frequent updates, it does'nt make sense to push all that in the SVN. What I do is either ignore those files through SVN or in some instances put a softlink to the files which are versioned. Dec 13, 2012 at 5:31

4 Answers 4


Well, nothing prevents from using Subversion for solving this tasks

Note: some steps may differ depending on layout of your own repository for themes/plugins (I suppose, they are dirs inside trunk, and the whole tree doesn't repeat standard WP-layout: /wp-content/themes/ wp-content/plugins/)

In order to start you have to have:

  • Empty Subversion repository, in which you can commit
  • Basic knowledges about svn:externals
  • URLs of all components (including WP-core), which you want to combine in "distribution"

Common rule:

All components are served in own repos, our repo only links they together in single place


  • Checkout (empty) trunk svn co URL/trunk Deploy
  • Write all components definitions in text file (externals.txt for sample) (save it in any place, it haven't to be a part of repo), it they appear in file something like

wordpress http://core.svn.wordpress.org/tags/3.5/

wordpress/wp-content/plugins/plugin-one URL-OF-PLUGINONE


wordpress/wp-content/themes/Mytheme URL-OF-MYTHEME

(each line is new externals definition, 1-st part - relative path to local dir, space(s)-separated 2-nd part - source of directory content)

  • cd Deploy
  • Use externals.txt for defining all externals in trunk's root at once svn propset svn:externals . -F ../externals.txt
  • Commit changes
  • Update (or checkout trunk into new dir) and see all: core, needed modules and themes collected inside wordpress dir

Next time, when you'll want to change configuration of deployable WP you have only edit existing svn:externals definitions ('svn propedit', 'svn commit') and get after checkout updated configuration.


I have one multi-site setup with WP pulled down from SVN, to update all sites all I have to do is the svn sw ... command and visit the upgrade page in wp-admin.

If all the sites are on the same server I'd recommend looking into multi-site.

  • I don't think that multi-site is a good option for us. Its very useful to have a series of different installs for our clients. It means that if any of our clients suddenly command more server resources we can move them with (relative) ease to an amazon EC cloud. Or if they wish to deploy to their own server in the future we can benefit from that as well. Unless I have misunderstood multi-site this would suggest one wordpress installation no no ability to easily migrate single sites. Do all sites have their own mysql databases? Or are they all amalgamated? Dec 15, 2011 at 14:21
  • Similarly updating each site separately allows for us to assess any potential incompatibilities with the new version on a more localised case, and lastly having a separate hosting account on our dedicated server for each client means that we can build other web apps and infrastructure around their wordpress installation. Dec 15, 2011 at 14:23

Use NetBeans... When you check out a copy from SVN, you can directly use it as source files for your project, and at the same time sync it with your server. NetBeans keeps a neat track of new files, changed files, you can compare revisions, commit, update etc. It's awesome, no command prompt needed (except for checkout/export/import which you do from command line/terminal).


We are using a PY script to check twice daily for updates via SVN. It correctly parses the /trunk/readme.txt file and reads the Stable Tag line and downloads the correct tag, or uses /trunk if that is correct. It also handles theme updates.

Feel free to use it from https://github.com/nikdow/wordpress_plugins/

You could provide this with a list of directories to update and run it from cron.

One advantage is that the files can all belong to root, so you are less exposed to hacks which insert PHP into writable directories in your webroot.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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