I've been really happy with Movable Type overall. It's free, I like the administration interface and the templating system, and it has the (minimal, admittedly) features I need. Last night while trying to move lemonodor between servers, however, I ran into two serious obstacles, both of which led me to think a little less of Movable Type.
The first problem I ran into was that the process of exporting my existing database and importing it into the new Movable Type installation did not preserve the IDs of entries. Unfortunately, entry IDs are used to construct the URLs of individual posts, which means that all URLs anywhere on the web pointing at specific entries would point to the wrong entry. For about 5 minutes I waffled on whether or not this was acceptable, but then I found these instructions on how to work around the problem.
Modifying the Movable Type source, exporting, putting out-of-order entries back into order, and inserting dummy entries to preserve IDs took about 45 minutes of tedious emacs work. Export/import that preserves IDs/URLs seems like a pretty basic capability.
The next obstacle was that even after all that work, about 300 entries into the import process the IDs got out of sync anyway. Movable Type seemed to think I had an extra 5 phantom posts in my database.
This problem was due to a totally amateurish bug in Movable Type's export/import.
MT's export format uses lines of dashes to delimit fields and records. E.g.,
---------- AUTHOR: jjwiseman ID: 453 ----- BODY: ... ----- COMMENT: AUTHOR: jjwiseman EMAIL: jjwiseman@yahoo.com IP: URL: DATE: 01/23/2002 10:52:18 PM Well, I installed OS X. But it feels too clunky to use an MCL that only works in Classic. -----
Unfortunately there were some comments posted to lemonodor that included long lines of dashes.
-------------------- (setf foo bar) -------------------- (print :woo-woo) --------------------
MT's importer was confused by this and treated each line of dashes as a delimiter for a new post.
Oops.
The very first thing I ask myself when designing a data format or protocol is “How do I ensure that I can save/transmit any data payload at all without getting it confused with the metadata that's not actually part of the content?” Not properly escaping dashes that appear in the body of posts or in comments is a real novice error.
Posted by jjwiseman at March 08, 2004 05:44 PMMT also repeatedly warns you to use MySQL instead of BDB. If you dump the MySQL db, you have a perfectly good export format.
Ignoring the advice of documentation is also "totally amateurish".
Posted by: anon on March 8, 2004 06:44 PMSo your excuse for MT's buggy export is to point out a non-MT non-buggy way to export?
When lemonodor started, there was no MySQL support in MT.
MT's export is buggy.
Six Apart's response to this bug is somewhat less than responsible[1].
[1] http://www.movabletype.org/support/index.php?act=ST&f=8&t=25474
Oh that is a totally amateurish data export format.
For instance, a non-ambiguous state machine parser for the ldif format is less than 2 screens of perl, and that's with blob field support.
They just need to add some code to check if an encoded field contains a delimiter, and escape it if it does, and un-escape on the other end, a la ldif blobs or something similar (there are a lot of ways to do this right. What a lame way to do it wrong).
But since MT has a free as in beer not as in speech license, I won't be donating code for it.
Were it GPL, MIT, BSD or even the dreaded Moz, I could stand it. As is it's worse than Sleepycat.
Posted by: David Mercer on March 8, 2004 07:50 PMThat wasn't the response of "Six Apart", John, that was the response of a user in the MT support forums. Big difference.
Posted by: almuhajabah on March 9, 2004 03:40 PMGood point. As far as I can tell, Six Apart hasn't responded at all.
love your pics of sunset juntion. but here are others
http://www.cs.ucla.edu/~kulisics/images/events/sunset_junction_2003/frame_sunsetjunction2003.html
Posted by: me on March 9, 2004 05:17 PM