blivet.com

Ugh. I was in love with WordPress for over a week. And I must admit it was fun while it lasted. I almost had the entire site converted to the new personal publishing platform and planned to “throw the switch” this weekend. In the process, I found several bugs in WordPress but managed to either fix them myself or work around them. Its PHP code is a bit sloppy but quite hackable. And I found its community of developers to be helpful.

Sure, the WordPress “Texturize” engine has a nasty bug which made it incorrectly encode many of my posts. In fact, if I had used it now it would incorrectly encode that previous sentence because it has quotes around a link. Ugh, again. But I worked around that too because I’m clever and persistent. Or at least persistent.

But then I found the “big” bug. The deal killer. The bug from which there is no workaround. Other than maybe a rewrite because, as near as I can tell, this is a fatal flaw in the design of WordPress. This is a flaw that prevents WordPress from having reliable permanent links to date-based entries, which is sad since “clean permalinks” is a big feature in the latest release. And it’s all due to the format in which WordPress stores and then retrieves dates from a MySQL database.

I will attempt to explain. But first, a little background …

Systems like Movable Type store blog entry dates based on the current time at the server installation, with an optional offset if the author is in a different time zone. For example, this would be Pacific Standard Time (PST) for my site. I don’t use the optional offset since I live in the same time zone as my server. Whenever Movable Type builds a SQL query for blog entries by date, it doesn’t need to make any adjustment to the input dates.

WordPress stores blog entry dates in Greenwich Mean Time (GMT). Whenever WordPress builds a SQL query for blog entries by date, it must make an adjustment with an optional offset for the author’s current time zone. For example, this would be 8 hours for me during Pacific Standard Time (PST) and 7 hours during Pacific Daylight Saving Time (PDT).

For about six months of the year the WordPress system works fine, providing the author doesn’t move between time zones. But when it’s time for everyone to change to or from Daylight Saving Time, the WordPress system breaks down. What happens? All the blog entries which fall outside the new time zone are shifted by one hour, possibly breaking date-based permanent links!

It’s easy to see the potential for this breakage in my previous blog entry. I posted that between 11 p.m. and midnight on Thursday, March 11. If I was using a date- and title-based archive nomenclature then the permanent link might be:

/archives/2004/03/11/spam-is-driving-me-to-wordpress.html

Or some such. Well, as soon as Daylight Saving Time kicks in on April 4 of this year, that blog entry will suddenly be shifted to March 12 between midnight and 1 a.m.! Which means that WordPress would change its permanent link as well.

What’s worse is that this can’t be easily fixed in WordPress. You can’t just adjust for Daylight Saving Time in the SQL query because you could be getting back a range of results across time zones. Storing the dates in GMT essentially loses the context of the original time zone in terms of the way WordPress constructs its SQL queries.

Even though WordPress is very powerful and versatile, this date shifting really sucks. Especially for someone like me who’s made a large number of posts around midnight. Like this one.

Which is why I’m now seriously considering Textpattern as my new content management system. It’s also a PHP- and MySQL-based system like WordPress. But it stores and retrieves dates like Movable Type. Whew! More importantly, it’s very easy to use and is quite stable for a “gamma” release, whatever that is. Textpattern may not be as flexible as WordPress and you have to sort of buy into its author Dean Allen’s way of thinking about content management to enjoy it, but that didn’t really bother me as much as WordPress’ date shifting. The horror.

Textpattern has Textile built into its nifty web-based site and post editor. Textile is a formatting engine for translating carriage return-based input to HTML paragraph markup and special punctuation characters to HTML entities (like SmartyPants does). But Textile also has a shorthand language for doing even more complex markup like links, lists, and tables. Pretty cool stuff. Of course, a Textile plugin for Movable Type is available from Brad Choate.

There’s a few things Textpattern doesn’t support like Trackback, but I never used that much myself. One annoying thing is that the current version doesn’t appear to support external editors like NetNewsWire and ecto. However, the web-based editor is so good and I’m such a browser geek that, in a way, this is actually a big draw for me. Anyway, I’m so serious about Textpattern that I’ll likely switch over to it in the next few days providing I can get new site templates written quickly enough.

Also, I did wind up installing MT-Blacklist to help stem the tide of spam while I’m still on Movable Type. And, so far, it’s working very well, catching 100% of all my comment spam. It was easy to setup and manage. I recommend it highly if you’re waiting on Movable Type 3.0. Which I may be doing as well if Textpattern doesn’t work out like I hope.