Tag Archives: subversion

Upgrade WordPress Install to Use SVN Externals

I recently wrote a post about setting up a new wordpress site using svn externals to include the wordpress core and optionally themes/plugins with a fresh svn repository. I’m now going through previously setup sites and changing them over to this new structure and thought it would be worth a quick post to take note of the steps I took to complete that.


  • a svn repo with wordpress installed in the trunk
  • a checked out working copy and you are currently inside this dir
  1. Let’s start by adding the wordpress core as an external to the root of our current working copy
    svn pe svn:externals .

    Enter in the following:

    wordpress http://svn.automattic.com/wordpress/tags/3.1.2


    svn up

    You’ll now have a wordpress dir with the core of wordpress.

  2. With a new wordpress core we don’t need the original base of wordpress that we had so let’s remove the php files in root as well as the includes and admin folders. You need to keep your wp-content folder as that’s where all the custom wordpress stuff goes. You also need to keep your wp-config.php and the .htaccess (as well as any other non-wordpress files that you may have stored here).
    svn rm wp-admin wp-includes index.php wp-activate.php wp-app.php wp-atom.php wp-blog-header.php wp-comments-post.php wp-commentsrss2.php wp-config-sample.php wp-cron.php wp-feed.php wp-links-opml.php wp-load.php wp-login.php wp-mail.php wp-pass.php wp-rdf.php wp-register.php wp-rss.php wp-rss2.php wp-settings.php wp-signup.php wp-trackback.php xmlrpc.php
    svn commit -m 'remove original wordpress files and add core via externals to ./wordpress'
  3. Now we just need to modify the config and htaccess to handle the new structure and we have the base done.
    vi wp-config.php

    Be sure the following is included (after the WP_HOME is defined, I always make sure I define my WP_HOME and WP_SITEURL just to be sure it’s correct when I move from dev to staging to production):

    define('WP_CONTENT_URL', WP_HOME.'/wp-content');
    define('WP_CONTENT_DIR', realpath(ABSPATH.'../wp-content'));
    vi .htaccess

    Replace this piece in the .htaccess:

    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]

    With the below content:

    RewriteCond %{REQUEST_URI} ^/wp-(.*)(.php) [OR]
    RewriteCond %{REQUEST_URI} ^/wp-includes [OR]
    RewriteCond %{REQUEST_URI} ^/wp-admin
    RewriteRule ^(.*)$ /wordpress/$1 [L]
    RewriteCond %{REQUEST_URI} !^/wordpress/
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule ^(.*)$ /wordpress/index.php
    RewriteRule ^(/)?$ wordpress/index.php [L]
  4. If you have any standard plugins you can replace them with the svn repo that is provided by wordpress via externals as well (if they exist). I’ll use wptouch as my example:
    svn rm wp-content/plugins/wptouch
    svn pe svn:externals wp-content/plugins
    wptouch http://plugins.svn.wordpress.org/wptouch/tags/1.9.29/
    svn commit -m 'replace wptouch plugin with a svn external copy tagged 1.9.29
    svn up

    This will only work with plugins that have svn repositories, such as ones available in the wordpress plugins repo or a third party provided repo. I’d recommend sticking with a tagged version and just changing the tag to the newest version as you see fit. If you prefer to stay on the bleeding edge you can easily use the trunk. The one thing to note about using the trunk is that you do need to run a ‘svn update’ in order to get the latest version from the trunk, it’s not pushed to you, so you are still in control.

Subversion file removal

I performed one of my no-no’s today by accidentally adding my wp-config.php file to a svn repo full of database password goodness. That’s not good. Anyways, it’s a simple enough procedure to revert the issue and continue on with your complete repository as it was just without that file and it’s contents.

cd /var/svn
svnadmin dump repository-name > ~/repository-name.dump
svndumpfilter exclude trunk/wp-config.php < ~/repository-name.dump > ~/repository-name.dump-new
mv repository-name repository-name.bak
svnadmin create repository-name
svnadmin load repository-name < ~/repository-name.dump-new

A quick line by line explanation:

I start off by dumping the repository into a dump file (great, we now have a backup, but you were already keeping backups anyways). Then with the svndumpfilter
we exclude the nasty file that you don't want and put that into a new dump file. Remeber that it's relative to the root of the repository so if you put stuff into trunk you need to prepend your file with trunk, also it does not search out that file name recursively, it's directly getting that specific file. Now that I have my new clean dump file I will backup my repository directory just in case I make a mistake and then create a new repository and finally I load that new repository from the new dump file. That's it!

A final note, I did have to checkout my local working copy again after this as it was still under the impression that the wp-config.php file was still versioned. Probably because it wrote that to the local .svn folders and it doesn't check that again in the repo, I'm sure there would be several ways to correct that but this was simple enough to do.