Feb 6
Sweet
icon1 Niklas | icon2 Tags: , , . | icon4 02 6th, 2008| icon3No Comments »

Did I mention upgrading WP is now completely painless:

$ svn propset svn:externals "wp http://svn.automattic.com/wordpress/tags/2.3.3" .
property 'svn:externals' set on '.'

$ svn up

Fetching external item into 'wp'
U    wp/wp-includes/gettext.php
U    wp/wp-includes/version.php
U    wp/wp-includes/pluggable.php
U    wp/xmlrpc.php
U    wp/wp-admin/install-helper.php
Updated external to revision 6736.

Fetching external item into 'wp-plugins/openid'
Updated external to revision 30920.

Fetching external item into 'wp-plugins/akismet'
U    wp-plugins/akismet/akismet.php
Updated external to revision 30920.

Updated to revision 292.

$ svn -m "Upgrade to WP 2.3.3" commit .
Sending        .
Transmitting file data ..
Committed revision 293.

Technorati Tags: ,

Dec 26

Is this thing on? protocol7 has been broken for a few days due to an upgrade at my hosting and me being lazy over the holidays and not reporting it. Now, the Joyent support has fixed it and we should be back online.

This event reminded me that I needed to revisit my site configuration. I keep the entire site (except for the stuff that MySQL stores for me) in Subversion. The live site is simply a checked out working copy. Whenever I need to make an update, I do that locally on my laptop and commit the change to SVN. Then run a simple svn up on my server and it’s all done. This setup gives me a lot of confidence in knowing that all changes are safely stored and I can easily retrieve old working versions to rollback any bad update. In this case, this helped me a lot since one of the problems was a file that was mysteriously missing on the live site. svn up fixed that immediately.

I’ve also used the SVN installation method for Wordpress. However, my customizations has been troublesome. Since SVN can not handle overlapping working copies, the files below the WP checkout could not be stored in my SVN. This included my themes and plugins, the files that I spend most time on customizing. No good.

Today I spent some time on fixing this. Please note that I know next to nothing about PHP.

WP installation

I now include WP automatically in my checkout using the svn:externals property. This means, that wherever I check out the site, SVN will pull down the version of WP I currently run.
svn propset svn:externals "wp http://svn.automattic.com/wordpress/tags/2.3.1"

Plugins

Plugins are normally kept in wp-content/plugins beneath the WP installation. Again, this means I can not store these in my SVN. However, the plugins directory can be customized by setting the PLUGINDIR variable. Create a directory in your site root wp-plugins and put this in your wp-config.php:
define('PLUGINDIR', '../wp-plugins'); // no leading slash, no trailing slash

Then, put all your plugins in wp-plugins and store them in SVN like normal. I pull down any plugin I can using svn:externals, currently Akismet and the OpenID plugin.

Themes

Themes are normally stored in wp-content/themes. To customize this path, you need to use a different method from plugins. The idea is to use add_filter to create a filter that changes the path. However, there are currently some issues with this approach (for example image paths in the WP admin GUI not using the filtered paths but instead handcrafting them) so I had to use a workaround. I’ve created a wp-themes directory in the site root, put my themes in it and stored it in SVN. Then, I create soft links using ln -s to link the themes into wp-content/themes. I’ll continue investigating this issue with the WP developers to see if a better solution is possible.

wp-config.php

wp-config.php must be kept under the WP installation directory. Again, I use soft links to keep my original copy in a custom directory and under SVN control. Note that as part of wp-config.php, WP detects its installation directory. When using a soft link, it will find the wrong root directory. Instead, I have changed wp-config.php to set the correct root directory explicitly:
define('ABSPATH', '/absolute/path/to/wp/');

Again, not exactly what you would like, but does the work.

Site installation

Installing or restoring the site can now be done using the following commands
svn checkout http://example.com/my/svn/repos .
ln -s wp-themes/mytheme wp/wp-content/themes/mytheme
ln -s wp-custom/wp-config.php wp/wp-config.php

Upgrading WP is done by changing the svn:externals property and then running svn up. Dead simple.

Technorati Tags: , ,

Oct 27

I just upgraded my Wordpress installation (the one used to publish this post) to the latest 2.3.1. Upgrading WP is easy, but boring so this time I decided on putting some additional work into the upgrade by switching to the SVN based install described here. Worked like a charm and future updates should now be as easy as running svn switch. I keep the rest of my site in my private SVN since a few years back. That means I would like to keep my WP customizations (like wp-config.php, plugins and themes) in my own SVN and then interleave their working copies to make up the final site. Haven’t yet figured out how to best do this. Tried soft linking my custom files into the WP checkout, but that blew up WP.

Apr 21
TSVN for Firefox
icon1 Niklas | icon2 Tags: . | icon4 04 21st, 2007| icon3No Comments »

If you’re using Subversion (most developers probably are these days) and you’re on Windows, you probably use TortoiseSVN. It’s arguably the best SVN client for Windows. And now it’s even better, with this snappy Firefox plugin you get the TSVN menus in the web frontend of your SVN repository. I tend to use Firefox for surfing around repositories and then switch to the TSVN repository browser to do any work, now I don’t need to. A great time saver.

Jul 23
Subversion troubles
icon1 Niklas | icon2 Tags: , . | icon4 07 23rd, 2006| icon3No Comments »

Lately, we’ve been having some issues with Subversion at work. We use SVN for all things that need versioning, mostly code but also documentation and deployed artefacts. Since we’re a fairly small company its not a huge repository (some 45000 total commits, approximatly 150 commits per day). Now, since begining of June some revisions has gone bad resulting in the following error on checkout or update:

Error REPORT request failed on ‘/repos/main/!svn/vcc/default’
Error REPORT of ‘/repos/main/!svn/vcc/default’: Could not read chunk delimeter:
Error Secure connection truncated

“svnadmin verify” outputted the following on examining the affected revision:

“insn 0 starts beyond the target view position”

After some Googling I found this write-up by Ian C. Blenke, describing the same problem as we see. After some discussion on svn-users and the excellent help by John Szakmeister, his fsfsverify tool now catches and fixes our first broken revision. He is still examining a second broken revision that currently breaks fsfsverify. But, since so far there hasn’t been any data corruption seen due to this bug I have high hopes for John being able to create a fix.

Update: John has now updated fsfsverify to also catch and fix our second broken revision.
So, if you’re seeing this problem, report it on svn-users, take a backup of your repository and try out John’s tool.