Using Subversion to deploy WordPress

2 Views

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.

Read More

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?

Post Views: 2

Related posts

Leave a Reply

4 comments

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

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

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

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