So, my hosting provider, Dreamhost, recently announced that they’d be discontinuing support for WSGI. My blog had heretofore been a simple one that I wrote myself, in Python, that used WSGI as the server interface. It was fun and educating to write, and it ran reliably for years, but once they dropped support, I had to find another option. FastCGI was still supported, I believe, but no.

In a way, I don’t blame them. Python, as great as the language is in terms of utility, readability, and straightforwardness, isn’t exactly fast, and is relatively resource hungry. And deploying it is a hellish nightmare.

I decided to throw in the towel and just use WordPress. It’ll probably be the right decision in the long run, but holy cow was it a nightmare to transfer data. Basically ate up a whole weekend.

First, to get it out of the way, PHP is a rotting carcass heap of a language. It’s abysmally bad. I know about a dozen programming languages, and usually when I see code in any language I can follow what’s going on with mild effort. PHP is like reading code through a CAPTCHA challenge, you know there’s something discernible there, but it’s a mental challenge just to make it out. Thus, I had no desire to dive in and code my way out of problems, which in retrospect was my first mistake.

My second mistake was trying to use the XMLRPC interface to transfer data. Where shall I begin with this mess? The XMLPRC interface itself wasn’t a huge problem. The problem was that, because XMLRPC is not your normal accessing pages from a web browser, the whole error handling mechanism just isn’t really there. A good chunk of my time was spent trying to guess why errors were happening with little or no explanation other than a server 500 error. To make matters worse, I had no control of many things on the host machine, and eventually I realized that the XMLRPC requests were being intercepted by anti-malware and rate limiting filters.

(Then there was this weird issue that Googling for anything about WordPress XMLRPC yielded hundreds of pages about how to disable it. I assume the articles were computer generated as part of a smear campaign, probably by someone owning a competing technology. The articles had that uncanny “every article is the same” feeling, even though they were worded differently.)

In the end, I ended up hacking together the following solution. I set up an older version of WordPress on a side computer (getting that to run was its own nightmare), and used a Python script to import data from my old blog using XMLRPC. Because it was on my own machine, I was able to disable the filtering, which solved most of my XMLRPC issues. Then I migrated that older WordPress to the most recent version of WordPress. (The migration turned out to be unnecessary. I had thought that the script I wrote was conking out on the post formatting used by the most recent version, but it turns out that was due to a technicality.) Once I had my local WordPress running and posts showing correctly, (which took two hours longer than it needed to thanks to a dumb cut-and-paste error in an Apache config file), I did a database export, which I then imported to the database on my web host, with a little surgery to adapt it to the new location.

The database import went remarkably smoothly after the trial-and-error disaster of using XMLRPC , and makes me think I should have just written the original script to update the database directly.

Anyway, it’s now done, posts are transferred and look good, and the theme suffices for now.