Conversion from Movable Type to WordPress

I’ve converted Movable Type to WordPress four times now (two sites, initially converted for evaluation purposes, then converted for real). Here’s the essense of what I did, the customizations I made, and what I encountered:

1. Exported data from MT, saving the data locally in a file named import.txt.
2. Copied import.txt to WordPress’s /wp-admin/ dir
3. Modified /wp-admin/import-mt.php from

   define('MTEXPORT', '');

   -to-

   define('MTEXPORT', 'import.txt');

   such that import.txt is the name of the file created in step 1

4. [This step is probably optional for most people, but not for the two blogs I’ve converted:]
   For the two sites, I overloaded the “Extended Body” field in MT. For one site, I used it as a news link, for the other it was used for moods. In both cases the field is not always defined for every post, and in the page templates, I needed to be able to ask if the field had data in it, if so, then wrap the data in certain HTML formatting. The “Extended Body” field fit those parameters, and wasn’t often used otherwise. However, running the import against the MT-exported text file resulted in those fields being tacked onto post body field, merged by “<!–more–>”, in WP.

   In WP, I wanted to take advantage of the very cool “Custom Fields” feature, defining a custom key (“link” and “mood”, respectively for the two sites) and use MT’s “Extended Body” text as the custom field value. I did so by:

   1. Commenting out this line:

      if ('' != $extended) $extended = "\n<!--more-->\n$extended";

   2. Changing this line:

      $post_content = addslashes($body . $extended);

      -to-

      $post_content = addslashes($body);

   3. After this line:

      echo " Post imported successfully...";

      Inserted this:

      // Now for link meta-data
      $wpdb->query("
              INSERT INTO $tablepostmeta
              (post_id,meta_key,meta_value)
              VALUES ('$post_id','link','$extended')
      ");
      

      UPDATE: I should’ve wrapped the previous command in an if ('' != $extended) { } so that the ‘link’ meta key wasn’t created for every post, regardless of whether it had a link or not.

      Where ‘link’ is the name of the custom field you wanted to create.

5. Ran www.sitename.com/wp-admin/import-mt.php
   • On an earlier install I received an error message similiar to that mentioned here at the WP support forum. As noted in the link, it seems to be a PHP memory limit problem only occurring on FreeBSD. The fix was to modify /usr/local/etc/php.ini and change this line:

     memory_limit = 8M ; Maximum amount of memory a script may consume (8MB)

     -to-

     memory_limit = 128M ; Maximum amount of memory a script may consume (8MB)

     After the change, Apache needed to be restarted.

   • On a second import (from scratch again) (which occurred after the MT blog being imported had accumulated more posts and comments since the previous import (only a few days or at most a couple weeks’ worth.. ~16 posts), clicking “let’s go” on the install-mt.php page returned a page with nothing but the WordPress logo on it.

     However, the problem was solved by the same memory_limit adjustment mentioned above.

   • I also discovered that though WP will successfully reimport entries for a site, and is smart enough not to create duplicate entries as a result, it does not do a very deep comparison. I haven’t looked at the code to determine how much of the entry it checks before deciding it has it already, but I know it won’t import newer comments for a post previously imported.
6. Just before the actual import of the data into the database, WP prompts for how all posts for each MT author should be remapped to existing (or new) WP authors. For all the cases I’ve handled, the blogs have only had one author. I wanted WP to assign the admin user (a re-profiled ‘site admin’ user whose name at that point matches with the MT blog’s author) to be assigned all of the posts. I DID NOT want WP to create a new user. However, regardless of how I left the entry field blank and chose the existing user from the dropdown, or how I other times defined a name in the entry field (which I understand to be tantemount to creating a new user with the name contained in the entry field), a new user was created to own all of the imported posts, usually with the same name as the already existing user. I must say I was miffed each and every time. I wound up having to execute the following SQL query directly into the MySQL server:

   UPDATE wp_posts SET post_author = 1

   Obviously, you’d have to use whatever your posts table is named if you had customized from the default used above. You might also be assigned the posts to an author other than the one with the id of 1. If you’ve got multiple authors, you’ll obviously need to customize a different SQL query. Then go back and verify that the newly created author(s) no longer has any posted associated with it, and delete him.

7. In php.ini, restored the memory_limit setting’s value to 8M