Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

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?

share|improve this question
    
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. –  kidakaka Dec 13 '12 at 5:31

3 Answers 3

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

Actions:

  • 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.

share|improve this answer

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).

share|improve this answer

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.

share|improve this answer
    
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? –  Thomas Clayson Dec 15 '11 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. –  Thomas Clayson Dec 15 '11 at 14:23

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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