MT learnings

This was the plan:

• Make sure you have local copies of all template files
• Make sure you write down all configuration options and paths
• Export content from all MT-controlled weblogs running at hebig.com
• Edit export file for consistency in text formatting (through batch search an replace in the flat text file)
• Delete the MT cgi directory and all related files (static archive files, static doc files, etc.)
• Do a clean install including all external libraries of the current MT 2.661 in a new directory
• Add neccessary plugins for text formatting (Textile 2)
• Import all old entries into new installation
• Rebuild all content

Several hurdles were to overcome:

• The export script times out on my server. Since MT does not provide for incremental backups, I had to create manual export templates, set a limit per export at 200 entries, export into seperate files, repeat this for about 10 times and then merge all export files into a master export text file.
• While mt.cfg stores most of general configuration options, there seems to be no way in MT to extract weblog-specific configuration settings (such as templates linked to files, time, archiving and comment configuration).
• The import script times out as well. So I had to manually search through the master export file, delete content up to where the import script timed out, and restart importing. Had to repeat this for about 12 times.
• Rebuilds still cough out "Out of memory during "large" request" errors.

A few minor (and major) surprises and learnings along with suggestions for future improvements:

• I had initially installed Jay Allen's mt-search script before it became part of core MT functionality. This has never been a problem up until I tried to use the new installation. As it turns out, the search script in the full MT bundle is slightly different from Jay Allen's original version and keeping seperate templates per weblog doesn't seem to work. Also, the search template is still not integrated into MT's "manage template" screen so messing with the search template is ugly manual (undocumented) work. A smoother integration into the overal MT configuration flow would be desired along with reviving the capabilites to store search templates on a per-blog basis.
• Permalinks are no longer permanent. This is, imho, a major flaw. Let me explain. Each MT installation gives you the option to run several "independent" weblogs. Now the issue is, those weblogs are not really independent at all.
• You may have weblogs A, B, and C. Now you post a first entry to weblog A and the ID associated with that article is ID 1. You post a second entry to weblog A, the ID is 2. But when you then post content to weblog B, that next entry becomes ID 3. And the next post to weblog C becomes ID 4, and so on. You get the idea. MT does not store a unique ID with each entry on a per-weblog basis. The ID is also not exported. Which in turn causes a major shake-down when exporting and re-importing content since there is no way to predict what ID a new entry will have. So you can't apply any .htaccess magic or other means to keep the previous URI of a post. Permalink numbering shifts. Outside links may now link to the "wrong" article while trackback reporting (stored with the exported content) still works.

Yes, of course, I could have renamed permalinks to a less MT-specific naming scheme (such as hebig.com/archives/yyyy/mm/dd/ID or similar) but then permalinked articles from third-party sites would have been messed up before the fresh install and not afterwards. The problem remains.
The fix? A unique ID per post per weblog that stays with the entry even when the entry is exported (just like it is done with the headline or the author name). It would certainly be a major improvement and solve permalink issues for good.
Related issue: Not only external links to perma-content breaks, also internal links (entries at hebig.com linking to other entries at hebig.com) break. There is no way to batch-update internal links. It can only be done by manual search for self-links, manual search for the new URI of the linked entry, and editing the entry. Lots and lots of work that would be redundant if MT kept a unique ID with each entry.