Moved to TextPattern

Tonight I moved my blog to TextPattern. I apologize for duplicates in the RSS and Atom syndication feeds due to a change in my permanent URLs. That was inevitable: I have planned the change for about a year. Unfortunately I ran into a problem with my fix to keep the old URLs working; I intend to remedy this over the next few days.

Although my articles are all here, the move is ongoing. I haven’t yet done much about the look of the site.

Until today, this blog was generated from OpenOffice documents using a collection of scripts. I had three reasons for doing this:

  • I had access to all of the features of a full-fledged word processor to write my articles.
  • Everything I wrote was in an open file format on my personal computer, not in some database on someone else’s web server.
  • It was cool, and it was my baby.

However, the system was clunky. Several months ago I realized it was time to switch to something else. I chose TextPattern (over WordPress and others) for its simplicity: the administration interface is clean, the code seems fairly straightforward, and I like how it handles nice URLs.

With TextPattern, I gain a comment system, searchable categories, and an easier publishing process. Equally importantly, I can take advantage of HTML features hard to coax out of OpenOffice.

I don’t lose that much either: I get already get local copies of my articles through my Atom feed, so that’s taken care of. If I want OpenOffice, there’s no reason I couldn’t write scripts to do that; after all, that’s how I moved my articles over.

But not all is peachy. I have already run into a number of limitations of TextPattern, and made a few minor customizations. Here’s what I ran into so far today:

  • For the Atom feed, TextPattern generates hideous entry IDs with random hash codes in them. I have changed these to something more sensible.
  • I need decent archives by month and by year. I believe there’s a plug-in out there to help with this.
  • The Atom feed uses encoded HTML for content instead of unencoded XHTML. This makes processing the feed a pain in the posterior. I’ve already changed my feed to regular XHTML – a somewhat risky move if I write broken articles.
  • Some of the built-in content tags generate invalid XHTML – for example, li elements are used as separators rather than wrappers in lists. I’ve fixed this for li breaks.
  • Some of the date formats exclude the leading zero for the day (e.g. 2004-07-2 instead of 2004-07-02).
  • The standard stylesheet uses pixel font sizes.
  • The stylesheet also makes no accommodations for printing.

But much of this can wait. I need to get back to writing.