WordPress withdrawal warnings

My first year in graduate school, I took a course in structural mechanics taught by Bob Eubanks, a remarkable man who combined highly theoretical research with a very down-to-earth personality. He was powerfully built, bald with a little moustache, and had a habit of making noises as he breathed that combined humming, growling, and snorting. The impression he gave was that of a bull.

During the final exam, he sat at a desk at the front of the class, reading the newspaper and occasionally looking out at us. About an hour into the test, he must have seen something in our faces or our frantic scribbling that bothered him, because he got up and walked around the room, stopping behind each of us and giving a little grunt as he looked at our test papers. This was not a confidence-builder.

When his tour was complete, he returned to the front desk. “Gentlemen,” he said, “if I might make a crude suggestion… If sex is a pain in the ass, you’re doing something wrong.”

He went back to his newspaper. We all looked at each other and then at our test papers. Most of us decided to put our pencils down and rethink whatever problem we were doing. Thirty years later, when I find myself struggling with a problem of any sort, I remember Bob Eubanks’ advice, put my metaphorical pencil down, and try to rethink the problem.

I thought of this while reading of the troubles Gabe Weatherhead and Justin Blanton have had in shifting their blogs from WordPress to a static blog system. The biggest problem seems to be extracting all the posts from the WordPress database into a set of text files. As I’ve been thinking about moving ANIAT to a static system, the difficulties they’ve run into have been of more than casual interest to me.

I’d always assumed I’d just use the WordPress Export command to make an XML file with all my posts, then write a little script that uses Python’s ElementTree library to go through each entry and turn it into a file. I’d even done the XML export and explored a bit with ElementTree using Python in interactive mode. It seemed to work well.

But simple tests with just a few posts isn’t the same as a full-fledged conversion. Both Gabe and Justin are awfully smart, and they still had trouble, so that XML export file may be filled with demons I’m not prepared for. I don’t want to set up a new blogging system only to find myself struggling with Unicode errors that I can’t run down.

So I put my pencil down and rethought the problem. What am I trying to accomplish here, and what’s the best way to go about doing that? How much time do I want to spend on blog administration? What do I gain by moving from WordPress to a static system?

I don’t have all the answers, but that in itself tells me it’s not time to leave WordPress yet. The most common reason to switch to a static blog is site performance, and ANIAT’s performance is currently pretty decent. Although it still has brief downtime outbreaks, they’re not because WordPress is overtaxed. The Hyper Cache plugin has seen me through some heavy traffic over the past 9-10 months, and I expect that to continue.

And I’ve never had the sorts of WordPress update problems Justin complained about:

Frankly, I’m just tired of having to upgrade WordPress (and then make all of my little one-off modifications each time I upgrade)…

For me, upgrades have always been a one-click affair, done at my convenience. They’ve never broken the site. This may be because I built the ANIAT deliberately to avoid the divs within divs within divs structure common to many WP templates. I made the mistake of using that kind of template when using Movable Type and promised myself never to do that again.

None of this should be construed as a vow to stick with WordPress through thick and thin; the temptation to write my own static blog system may overwhelm me. But if I do succumb, I’ll know, thanks to Gabe and Justin, that the first problem to be solved is exporting. If that turns out to be a pain in the ass, I’ll know I’m doing something wrong.


8 Responses to “WordPress withdrawal warnings”

  1. Rico Jones says:

    Just a thought, but what about approaching the problem from the other direction: write a script that visits every link on your site and scrapes your post content away from the template.

  2. John says:

    If you went to a “Static” site, would you do about comments? I think the commentator on ANIAT make a positive contribution.

  3. Carl says:

    @John,

    Disqus is JavaScript, so it works on static sites.

  4. jonc says:

    Going from a static site back to WordPress or something similar would bring its own set of issues. From what I see, import schemes usually expect XML generated by a specific platform, not raw HTML or raw Markdown.

  5. Gerry says:

    Withdrawl? You from the South now?

  6. Dr. Drang says:

    Shucks, Gerry, I’z jest funnin’ y’all.

    Honestly, I should never post after midnight.

  7. Jamie Phelps says:

    In my experience with WordPress, folks’ difficulties with upgrades tend to be a result of hacking where they shouldn’t hack. In my more naive days, I made customized versions of built-in themes by hacking them up directly. Now, I’m a little wiser and actually do child theming when I have occasion to do WordPress work. There are very very very few things that one would want to do that can’t be accomplished with a simple plugin that hooks into some action callback or a change in a child theme. All that is to say that your experience with WordPress sounds like it points to your having danced with it correctly so as to minimize your own pain with updates.

  8. Aristotle Pagaltzis says:

    If scraping the content out of the template as Rico suggests is an option, then there is a much easier one: WP’s feed generator supports paging. (The query parameter is called paged.) You can just flip through the feeds for posts and comments and pull out the entire content in a very friendly format.

    Either approach loses the original source in Markdown (or whichever format) though.