Sep 23 2004
Redesign and Move to WordPress
I’ve finally succumbed to the lure of WordPress. The migration was mostly painless although I find the php functions that WordPress uses somewhat limiting. I know I have the full power of PHP at my disposal now, but even so the default functions presuppose a particular style of HTML authoring. I’ve tweaked the default template to something I’m happy with. Visitors to the web site will see a completely new look and feel. All you out there in RSS-land should hopefully see no change 
Why did I change? It wasn’t because of the MT pricing. And it wasn’t because of slow rebuilds. In fact, the dynamic aspect of WordPress has been the main barrier to my switching. I’m somewhat uncomfortable with rebuilding a page from scratch on each request when I know it’s unlikely to change very frequently (as any regular visitors to this site can testify!). Also, baked pages can reuse all that lovely caching code and HTTP optimisations built into Apache. Dynamic systems end up re-implementing it, usually in an inferior way.
No, the primary reason for changing was comments. I’ve had a long love/hate relationship with comments on this site but recently I’ve had a couple of emails from visitors that would have been better posted as a comment. Anyway, I dislike the MT comment system intensly, the new centralised system even more so. WordPress brings one simple feature as core: moderation.
Finally, I’ve done my best to keep URIs the same between the old setup and the new but inevitably there will be some that I’ve missed. If you spot one, let me know. Hey, you could even use the new comments system on this post! How’s that for progress?
5 Responses to “Redesign and Move to WordPress”
Frist p0st!
Er. I mean, I see that your RSS autodiscovery link element has @type “application/rdf+xml” - while that does have the advantage over “application/rss+xml” of being an actual registered type, have you written a spec somewhere that describes its use for RSS autodiscovery? Since what passes for a spec currently says if @type isn’t “application/rss+xml” it isn’t RSS, I presume most things won’t discover it. Firefox’s Live Bookmarks certainly doesn’t (though my patch to make their autodiscovery spec-compliant hasn’t actually been checked in, or even noticed, so it’s not too late if you want to write a new spec, and get everyone with autodiscovery code to rewrite it).
Hi Phil. Strangely enough my Firefox (RC1) does discover all the links here. I’m of the opinion that what’s in the type attribute of the link ought to correspond to the actual content. I had a vague recollection of writing a cgi to check this kind of thing. Poking around a dusty corner of cgi-bin I found it: content type link checker which says the things I link to have the right mime types. I perhaps ought to add another link for rss+xml but then I’d have to hack WordPress to do the right thing with the resulting content-type. Also, would Firefox show four live bookmark possibilities?
Just added an additional link with type=”application/rss+xml” and href=” /index.rss” and Firefox shows three separate feeds on its popup menu. It’s definately checking for both rdf+xml and rss+xml.
Sorry, I was in a timewarp, where my patch to make it spec-compliant was already checked in. Usually when I hack stuff in like that, I take it right back out to avoid confusing myself, but this time I forgot. What I meant was “Firefox certainly willn’t in one future.”
Right now, if you have a link element with rel=”cause-explosion”, type=”chemical/vx”, and title=”Because I hate RSS” Firefox won’t discover it, but if you change to title=”RSS” it will attempt to use it as a Live Bookmark.
And if it wasn’t for all the bugspam it would send, I’d go add that one to my test-case attachment
Strange, all my links have title like “RSS 1.0 feed for this post’s comments” not RSS on its own.