In migrating from Typepad to WordPress, mod_rewrite and .htaccess are your friend…when they are not your mortal enemy. After going through a brutal conversion process, I can honestly say I’ve been from heaven to hell and back again with mod_rewrite. In the interest of helping even one person to avoid some of my misery, I thought I’d try to put a few aspects of the conversion to post. A forum member suggested that I add this to the Codex. Once I feel I’ve described the technical issues correctly (and not added any mistakes or wrong information) perhaps I’ll do that. Here is is my story:
Converting Typepad Permalinks to WordPress-Compatible Permalinks Using Mod_Rewrite
When migrating from TP to WP, if you want to allow websites and search engines using your old format permalinks to reach your new site, you’ll probably have to write mod_rewrite rules to do it. Alternatively, if you maintain your old site indefinitely, then you can use it to redirect to your new site. That’s not an option for TP since it costs $13 per month to maintain a Typepad Pro (advanced) blog on their server.
If you know what you’re doing and don’t care about losing visitors who use your old format permalinks, before or after exporting your posts to WP you can change every single old style permalink to the WP format. You can also reformat your TP image file names as well as they will conflict too. I’m not aware technically of how you’d do this in an automated way though I’m sure there are ways to do it (you certainly wouldn’t want to do this manually).
Here’s the reason why mod_rewrite can be your friend in the migration process. There is a built in naming conflict in that Typepad names permalinks like so:
https://www.richardsilverstein.com//2004/04/us_iraq_war_dea.html
while WP uses this format:
https://www.richardsilverstein.com//2004/04/us-iraq-war-dea/
Typepad Image Folder Path Conflict with WordPress
A separate problem is that in the Typepad environment, if you accept its default image upload settings when you upload your images, they may be stored in some weird folderpaths. I don’t understand why this is–I just know it happened in my case. Without having changed any image upload settings whatsoever during my stay with TP, I have images stored in three separate TP folders.
In addition, if you ever used TP’s domain (e.g. richards1052.typepad.com) before switching to your own domain (richardsilverstein.com), you likely have images stored separately from all your others within Typepad. Be sure you scour your TP image folders before you shut your TP account down. I learned this the hard way when, after shutting down my TP account yesterday, I spent all day today trying to restore scores of images I’d uploaded when I used TP’s domain (before I got my own). I had no ideas I had images stored at …richards1052.typepad.com/photos/…
It is very important if you want your image displays to work in WP that you mirror your TP image folder/filepath when you set up WP. Otherwise, if you accept WP’s default image upload configuration when you install WP, your old TP images will not display. Again, you may choose to accept WP’s default image upload config, but you’ll have to rename all those old image filenames to conform to WP’s default folder/filepath structure.
Even after setting up a mirror filepath/folder structure, you will probably not see most of your old images displaying in your WP blog. Again, this requires added mod_rewrite rules for the image display to work properly (I wish I could explain some of these technical issues better–all I can do is explain what happened and how we fixed it). As you will read below, Carthik Sharma wrote a complex set of mod_rewrite rules that provided for proper display of my images. But when those mod_rewrite rules were accidentally overwritten, I noticed all my images were gone.
A helpful WordPress forum member suggested that I post to the Webmasterworld.com Apache Server thread about my problem. Justin Womack**, an intrepid forum member there came to my rescue and wrote these rules which restored my images:
RewriteCond %{QUERY_STRING} ^/([^.]+)(\.htm) [OR]
RewriteCond %{QUERY_STRING} ^/([^.]+)(\.jpg)
RewriteRule ^\.shared/image.\html$ /%1%2 [R=301,L]
But this being mod_rewrite world, there’s never an entirely trouble-free solution. It seems when you fix one problem, you’ve accidentally caused another. So for some reason, after saving Justin’s new rules in my .htaccess file, my blog stopped converting old permalinks. I looked in the .htaccess file and saw this error:
# File modified on Thu Jun 23 15:26:28 2005 by server
# \xef\xbb\xbf# is not a supported htaccess directive
# # File modified on Thu Jun 23 15:15:28 2005 by server
# \xef\xbb\xbf# is not a supported htaccess directive
Justin says this is an error that should never have happened and that I need to ask my host why it’s causing a conflict. I asked BlueHost about this and they said they have no idea why the errors are occurring either. So now at least I have all my images displaying, but I’ve lost visitors who use my old permalinks until I can fix the conflict.
Anyway, here’s a link to my current .htaccess file. It includes the above error language and does not include Justin’s rules (also above) since the “not a supported htaccess directive” error seems to have removed them from the file (without causing me to lose the displayed images which Justin’s rules were designed to allow to display–don’t ask me to explain that one). But if you’re in my boat and need some ideas on how to get yourself “over” to WP, be my guest and take a look. Use it if it helps. And if you know mod_rewrite better than I and can fix, or shed any further light on my htaccess rules conflict, I’d be grateful.
Full-Size Images Associated with Thumbnails May Not Display
If you’ve created thumbnail/full-size image displays in your Typepad blog, you may find that Typepad’s folder path structure conflicts with WordPress so that some full-size versions of thumbnail images will not open once you migrate to WP. For some reason, TP was adding this folder filepath, “…/.shared/image.html?/…” to some, but not all of my thumbnails. By a mere fluke, I tried removing only that bit of the filepath and miraculously all my full-size images associated with thumbs were now displaying properly. Don’t ask me why or how. I don’t know. I just know it works (somehow). And that will suffice.
Mod_Rewrite Debacle
When considering my move to WP, I could see immediately that it would be complicated. I looked through the WP support forum site and the Codex material about MT to WP blog conversion and saw that Carthik Sharma was one of the forum “support mavens” on this subject. After e-mailing him about my problem, he bravely and wonderfully agreed to take the project on. He did virtually everything for me: installation, configuration, file export/import. In fact, this WP blog owes its existence almost entirely to Carthik and I can never thank him enough for what he’s done.
By the way, both the Codex material on MT/WP permalink conversions and the external links to WP users who’d successfully resolved this issue with fixes of their own–all these solutions never worked for me. Either they seemed to involve using your old blog to redirect visitors to your new or else I just couldn’t technically get the solution to work. This may’ve been due to my own technical deficiencies or some other reason, I just don’t know. Even though TP and MT use virtually the same code and work in very similar ways, I’m guessing there’s enough that’s different to cause good MT solutions for conversion not to work for TP blogs.
Carthik also originally wrote mod_rewrite rules which converted the old TP link format into the new link format so those following my old links could get to the same posts but in my new WP environment. But in working with the .htaccess file subsequent to that I must’ve somehow added code or a rule to it & in saving it somehow overwrote all of Carthik’s rules. Naturally, neither I nor Carthik had saved a copy of his rules. This is when you enter mod_rewrite hell. So he was forced to start over again and finally 10 hours or so after he began working on the problem we had a second set of rules which now work. Which goes to show–always maintain a copy of yr. .htaccess file on your server in case you do what I did. Better to have a copy than to have to recreate hours worth of mod_rewrite rules.
My fellow WordPress user and friend, Chip at The Binary Circumstance, who also just migrated from Typepad to WP told me that he too overwrote his mod_rewrite rules accidentally. I’m not really sure why it should be so easy to overwrite .htaccess. I wish there were a surefire protocol built into htaccess that would prevent this from happening.
For anyone reading this who knows more about .htaccess or mod_rewrite than I–and who finds that I’ve made an error here–please correct it for me. I want this post to be as accurate technically as it can be & I’m by no means an expert in this area.
Finally, when all is said and done it would’ve been almost impossible to do this conversion right without mod_rewrite and as of now, I’m 95% of the way there. When mod_rewrite works as you want it to it gives you the most liberated feeling in the world. But it sure does require a lot of hand-holding to get you where you want to go.
**Justin has created an interesting new mini-app which he’s calling Automated Article Adder. As he describes it, it’s a self-contained method to create website or blog pages without all the added software, installation, configuration and code. On a single page, Justin gives you every means you’ll need to create web pages and with almost none of the technical hassles that those of us face who personally maintain and code our sites. So, clearly this application is aimed at someone who wants to create blog or web pages but isn’t interested in learning all the technical stuff one has to master to do it. It’s perhaps an entry level pathway for those who know little about blogging but wish to try it. With the explosion of interest in blogging over the past year or so and hundreds of thousands of new bloggers minted each year, he should find a market for this useful product.
