Practicalmadness

I’m currently rolling fast and loose on this site, having installed the beta release of Movable Type 3.3 last week. The biggest change from my viewpoint is the addition of native tag support. Since earlier this year I’ve been using the MT-Tags plugin to handle tagging on Practicalmadness, which involved using the Keywords field to automatically spawn a bunch of Categories in a very tag-like way. The new Tags feature eliminates the need for this, but creates a few new issues in the process.

Whereas before “tagging” was just a rather agile interface to the existing Categories feature, a Tag is now a completely new organizational construct. Previously a post could belong to zero or more categories (which I was calling tags). Now it can belong to any of those categories as well as zero or more tags.

This means that my investment in categorizing posts is now more or less wasted, and because MT helpfully converted all my tag-categories into real tags on upgrade, I’ve now got a whole bunch of useless singleton categories, just because I happened to list something other than one of my 4-5 “core” categories first when I was tagging an entry.

However, that’s not the end of the world, as I can just go through and fix up my templates to use the Tag construct instead of Categories, and we’ll be 100% okay. Sure, the template tags for tagging are currently undocumented, but when has that ever stopped me from doing something cool?

The bigger aesthetic issue is this: browsing your entries by tag is now handled by MT’s built-in search feature, and the URLs are atrociously ugly. Currently to browse a tag on this site you go to http://practicalmadness.com/tag/TAG_NAME. This is really just a Category archive (since tags used to be just categories), which was perfect because it meant that “tags” could have their own archive page design and some lovely, usable URLs.

Now we’ve got crap like this:

Movable Type was never really designed to be a dynamic publishing system. (“Dynamic” here means that pages are generated by the system when you ask for them, as opposed to a “static” model where pages are generated and cached to disk when I save the content.) Sure, a PHP-based dynamic option was introduced back in MT 3.0, but it’s never really been more than a hack. MT itself has always been a Perl app that builds static web pages, and MT feels most itself when you’re working only with the original, static stuff.

Since the earliest days, to get clean URIs (like /entry/202/some_stuff, and as opposed to entry.php?id=202&view=html) with MT required some .htaccess trickery and liberal use of the Archive File Templates feature that lets you customize where files are saved to disk. Now I’ve got to figure out how to fool the MT-Search CGI script into believing it’s got the information it needs, while passing it a URL like /search/tags/Ruby%20on%20Rails. Which is really, truly more hacking than I’d prefer to do to get a $69.95 piece of commercial software to do what I want.

And if I’m going to have to do that to deal with that CGI script, why not have all my pages generated by a CGI script? And provide a standard way of passing pretty URLs to them?

And finally, one other thing: MT’s idea of what constitutes an entry still assumes that all entries are formatted the same way, and its cross-blog support is still unbelievably lame. If I want to show Recommended links inline with my posts, I’ve got to use three plugins and spend a day hacking everything together, and that’s just for a straight chronological view on the homepage. I’m not sure if it’s even possible to offer cross-blog tag search, while displaying each type of post in its own format, because the search CGI script assumes that all the entries follow the same structure.

That’s really not a great assumption, and it gives me yet another reason to keep working on my Rails blogging app so I can evolve this site beyond Movable Type’s constraints. I don’t need perfect flexibility, but to not be able to mix together two kinds of text-based post without having to force them into the same data format is just looking more and more unreasonable.

That Being Said..

Since posting this entry earlier today I have:

• Switched the tag listings on each individual entry page from the old way to the new way

• Redone the Tag Browser (which is this site’s excuse for a tag cloud) to use the built-in tag ranking rather than my previous hacked-together solution

• Beautified the tag search URLs as described above; tags are now available at /search/tags/TAG_NAME and links throughout the site should reflect this format.

• Styled the search results page to match the rest of the site.

So switching from MT-Tags to real MT tags isn’t the end of the world or anything — it’s a mild inconvenience, and I still think tags aren’t going to help bring MT any closer to being modern, but at least I can say making the migration happen takes hours rather than many hours, days or oh god help us.