My own URL shortener

So I guess the modern equivalent of the vanity email address is the vanity URL shortener. I registered ian.lc because it was available and cheapish and because bit.ly’s links keep getting longer and longer.

I tried both Google’s and Bit.ly’s BYO domain shorteners and didn’t like them at all. Google forces you to use a subdomain and Bit.ly uses the same namespace for all shortening domains, so all it really offered was vanity, not improved shortness.

After a couple of wisely aborted efforts to write my own I just installed YOURLS, a simple, straight-forward, extensible URL shortener. Like all useful internet software it’s all PHP and MySQL so it took virtually no time to deploy – unzip, create database, edit config file, reload.

There’s a pretty good WordPress plugin that shortens a link and then posts to twitter that I’m experimenting with as a way to encourage myself to make longer than 140 character posts. Let’s see how that goes.

Give me convenience

I used to track WordPress updates, plugin updates and my own manual site changes using git. I wrote a whole post about it. Either fortunately or unfortunately WordPress launched their update framework which is so much easier than what I was doing. I’ve given up on my old technique and moved to using WordPress’ update mechanisms.

Of course what I really want is to be able to white a WordPress plugin that is notified any time an update occurs or a file update completes so that I can automatically track site changes in a SCM, but I don’t think that’s easy right now.

Tracking WordPress using Git

Update: I don’t do this anymore.

I publish this blog through WordPress, for reasons I’ve outlined before. I run it with a custom theme and a bunch of plugins though, and I wanted a convenient way to keep my WordPress install up to date without having to reinstall everything all the time. I wanted source control for my blog install.

My first attempt involved mirroring WordPress SVN into a Git repository on github so that I had a Git version of the SVN tree (including branches, tags and every checkin separate) and seperate repository holding the changes I’d made for my web site. This eventually failed for two reasons, first the script I was using to mirror the SVN into Git had a habit of failing in bizarre ways and secondly having two repositories confused me.

Yesterday I decided to update my fairly outdated WordPress install, it had been missing security fixes for some time and was one minor version behind. Since tracking SVN hadn’t worked I tried a simpler approach, a single Git repository containing a master branch that tracks releases and an ianloic.com branch to track the state of my site.

I set up master with a fresh download of WordPress 2.5 from wordpress.com, created my ianloic.com branch and applied the differences between my site and the 2.5 SVN tag (for all it’s failures my old approach at least let me do this easily). I switched back to the master branch, deleted all the files (leaving my .git directory intact) and unpacked the new WordPress 2.6.1 tarball. I checked that in (to the master branch), tagged it 2.6.1 and then merged that into my ianloic.com branch. I pushed all that to github and then checked it out on my web server (at Dreamhost).

Normally with Git you’re tracking just the master branch, but I want both master and ianloic.com branches to be tracked so my .git/config contains:

[remote "origin"]
	url = git@github.com:ianloic/wordpress.git
	fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
	remote = origin
	merge = refs/heads/master
[branch "ianloic.com"]
	remote = origin
	merge = refs/heads/ianloic.com

Now it’s easy to track changes that I’m making to my site and update to the latest WordPress without risking losing anything. The process for updating to a new WordPress release is:

  • on my laptop check out the master branch
  • rm all the files except for .git from the directory
  • unpack the new release into the directory
  • git-add . — now git-status will indicate what has changed, been added or removed
  • git-commit to check in the new version of wordpress
  • git-tag versionnum to tag which version is currently in master
  • git-checkout ianloic.com
  • git-merge versionnum to merge the latest version into the site’s branch
  • git-push –all –tags to push all the branches and tags to github
  • on my web server, git-pull to update to the latest release

I end up with a tree that looks like this:

ianloic.com WordPress in Git

Moving from Drupal to WordPress for blogging

I really like Drupal quite a lot. It’s powerful and flexible, it’s code is clear and well written and it’s extension mechanism is one of the best I’ve ever seen. All this flexibility tends to distract me from actually writing blog posts. So I’ve moved back to WordPress. If you’re reading this over RSS expect the usual disruption.

I first discovered WordPress late in 2003 from Mark Finlay, an Irish GNOME contributor. On December 24th 2003 he posted:

Everyone go look at WordPress: Seriouslessly sexy blogging Software, looks like it’s gonna kick MT’s ass.

I did, and in the end he was right. Unfortunately he died January 10th 2004. WordPress always reminds me of the three months when we lost Ettore, Chema and Mark.

There were a few scripts around for moving Drupal posts to WordPress but they were all pretty out of date so I took one and updated it. It has a lot of commentary in it. Take a look: drupal-to-wordpress.sql