Notes on Migrating Flatpress to WordPress

I’m going to post up some notes on the process of migrating my content from the Flatpress (wordpress-like flat-file backed CMS) instance at my old blog to a WordPress (the dominant CMS for blogs, MySQL backed) instance here at pappp.net.  The short version? It is seriously aggravating. Long block of text follows.

Before moving anything over, the first step is to set up a new WordPress instance, then go into the MySQL database, make the account you want to own your old posts UID=1, and wipe out the wp_posts, wp_comments, wp_terms, wp_term_relationships, and wp_term_taxonomy tables. Anything left in the tables will most likely cause key conflicts and make the import fail.

The first and most important thing I wanted was to move all the old posts, with as much of their metadata as possible, to the new site.  There is a helpful script made by some community members to facilitate this process, with some massive shortcomings. The script does extract a nice sql file with the text of all old posts, including the title, date and time, author (as numeric ID), and comments. It also generates part of the SQL needed to import the categories, but not all of it, and none of the old category information comes with the post. The biggest thing it DOESN’T do is have any mechanism for fixing internal links or images.
Some parts of the internal linking problem are easy to solve; moving the fp-content/images and fp-content/attachs directories to somewhere accessible on the new server, and subsequently doing a global replace in the dump of the old path to the new path. Likewise, links to other posts or statics will remain pointed at their original location. Since Post IDs are assigned in ascending order by date by the export tool, there is in principle the option of scripting the update, but I only had about 50 to handle, so it was fastest to just manually copy the date out of the end of each URL, regex it into the date format used in the export, find, make a table to match old URL to date, and hence ID, then replace with the new ID based permalink format.

There is also a problem in that some things don’t move at all with the script: the worst example is that because FP tags each post with a list of category ID numbers, and WP uses a table to associate posts with tags, indirected with another table to mark some tags as categories, it is essentially impossible to programmatically move the category information. One part of the category move which IS easily scripted is the addition of insert statements for “the other half” of each existing categories, like the following: INSERT INTO wp_term_taxonomy (term_taxonomy_id, term_id, taxonomy, parent ) VALUES ( 1, 1, 'category', 0);, where the values are the ids for the old categories, and the parent field points to the id of each category’s immediate parent. I ended up just doing it by hand in a 2-hour OCD-fueled manual retagging spree. Statics are the same way, and since the markup is incompatible, and the HTML handling is a little quirky, moving those has been almost entirely manual as well, and a few (notably the old projects index) are still not up.

I also programmatically tagged all the imported posts as “oldblog” by adding

INSERT INTO wp_terms (term_id, name, slug, term_group) VALUES ( 12, 'Old Blog', 'oldblog', 0);
INSERT INTO wp_term_taxonomy (term_taxonomy_id, term_id, taxonomy, parent ) VALUES ( 12, 12, 'category', 0);
INSERT INTO wp_term_relationships (object_id, term_taxonomy_id)
SELECT ID, 12
FROM wp_posts
WHERE ID<=$NUM_OF_OLD_POSTS
to the end of the import sql. Note that $NUM_OF_OLD_POSTS is the largest ID assigned by the script to the old posts.

I'm kind of unimpressed with WordPress, it is unnecessarily dynamic (and hence resource intensive on some of the less ...capable... devices I use), has a very weird two-page preview behavior, and uses raw HTML (which it then violates various ways internally) or a terrible visual editor for markup, but it seemed like the most obvious target, and is definitely a step up from the fragile old FP instance. Most of the issues may be fixable with plugins and/or themes, but that hasn't happened yet.  I might try placing the content into another CMS (NOT and in-"production" move like this one) just to play with my options, but it isn't likely while I remember what a pain this was.