movable type’s future

Well, this is just one of those times when I wish I was a better perl hacker. It’s just as useful to wish for that as it is to wish that MovableType was tested *completely* before shipping.

Why am I down on MT? I decided to try an experiment to see why the simple solution of renaming the comments script wasn’t working on my site, why mt-comments.cgi was always invoked on previews. I removed mod_perl from my installation to see if that was the difference. Apparently, it is.

It turns out MT partly ignores the configuration in mt.cfg (where you note the name of the script you want to use for comments, trackbacks, et al): it uses the configured name for direct posts without a preview but if you preview, it looks for the mt-comments.cgi script. So a spambot can still insert comment spam by invoking the factory standard command.

This all comes back to two things: MT’s performance issues and the comment spam problem. So far I have had two spam solutions proferred, both with the argument “hey, it works for me” and both of them fail.

The solutions have been to either use MT-Blacklist or simply rename the comments cgi script to make it a little more difficult for robots to exploit it.

Trouble is, I have been running mod_perl in my installation, to get around the slowness of MT (when you get upwards of 1000 entries, the lag becomes a problem for commenters: this is a design issue with MT: I can’t see any reason why the process has to complete the rebuilds and pings before acknowledging the user’s post). And as it turns out, neither MT-Blacklist or a renamed mt-comments.cgi will work in a mod-perl configuration. MT-Blacklist just fails to properly show the configuration screen, and I have confirmed with the author that it doesn’t work under mod_perl. With his announcement that it’s unlikely MT-Blacklist will be released in an MT3 compatible version, it seems similarly unlikely it will be updated to use mod_perl in 2.x.

That’s understandable: it’s a plugin, and if it doesn’t work, I can live with it. But when a component of the core product doesn’t work under an allegedly supported environment (mod_perl is in the docs, so I assumed everything would work just fine), what’s up with that? This suggests that testing in all supported environments (and encouraging plugin developers to do likewise: that or make the API take the load off the third-parties altogether) isn’t happening.

Now I’m back to a cgi-based installation and I’ll see how that does.

Perhaps WordPress is worth a look: TypePad isn’t, since this self-funded operation doesn’t even cover the costs of “free” hosting (cable’s cheap but not free).