Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×
User Journal

Journal Journal: ImMovable Type

All in all, I'm pretty impressed with Movable Type. It works with postgres, and memcache, and it publishes static HTML so it stays performant under heavy load. They do a lot of things well.

Although, the install process sucks. It croaked because I didn't have a certain perl library installed. No big deal though; one command in CPAN, and that's taken care of. Then it gets into the database building phase, and dies. Hard.

Turns out there's been a show-stopping bug in the release version for over a month. I understand; bugs happen. But when your release version has a bug that prevents installation, you've gotta have a fix out in far less than a month!

Well, I applied the fix mentioned in that post (which involved opening up a perl file and adding a line of code), and everything else went smoothly.

That was, until we decided we wanted to copy the installation from our dev environment into production. Our graphic artist spent dozens of hours setting up templates, building content pages, tweaking the configuration, etc. MT has a "import/export" system, but it doesn't capture most of these things -- just blog posts. It also has a "backup" feature. But apparently the "restore" half of that feature is slated for a future release. It's conspicuously absent from the relevant section of the docs. And an unanswered post in their forums notes that docs for a future release mention a "restore" tab that doesn't exist in the current version. Gee, I really hope there isn't some hapless blog admin out there dutifully creating backups that they'll never be able to use.

I google "moving movable type", and turn up a guide from 2004 that recommends, as part of the process, printing pages of the admin interface, and using a pencil to check the checkboxes, so you'll have something to refer to when you manually set them again. That can't be a good sign.

Alright, fine, I'll do this the good old fashioned way. I dump the database to a file, and tar it up along with the static content directories, gzip, and scp up to production. Unzip. Untar. MT comes up. Good. Republish. Error. It's trying to publish to the path the development server used. Huh? The config file is pointing to the right place. I put some symlinks from the paths the dev server used to the right places. Republish. Success! Wait... all these links point to the development server! I grep the database dump. Oh, great. The hostname, and the filesystem path are stored all over the goddamn database.

So I did the only thing I could. I ran sed to replace the old hostname and path in the database dump. It worked. But good god, could this be any worse?

tl;dr: MT's install process was broken for over a month; there's a "backup" system but no "restore"; there's no way to move an installation across domains; and the paths in your config file are copied all over the database.

This is state of the art blogging software? Face, meet palm.

Slashdot Top Deals

When the bosses talk about improving productivity, they are never talking about themselves.