A static WordPress

If you have been within earshot of any technology blogs in the last few years, you’ve probably heard about static web sites being a good way to power a blog.

It makes sense. Most weblogs http://web.archive.org/web/20130831044950/http://en.wikipedia.org/wiki/Static_web_pageare just for reading. They need to change when there’s an update, unlike a web app like Health Month or Mint that needs to change every time you visit. At most, updates need to happen whenever a new comment is posted, but that’s if you have comments and if your comments aren’t handled by an external service like Disqus.

Why should a bunch of PHP stuff and database queries run every time someone wants to read something? All that does is slow things down, and if you had a lot of traffic, it would cost you money.
A bit of last weekend and some of today, I decided to move Death Mountain to a static weblog. I didn’t truly need to do so; I don’t post that often, and I don’t get much traffic. However, I do have concerns about my current web host, and I’d like to not be tied to hosting that provides WordPress.

Mostly, I think that I wanted to do a bit of low-stakes messing around. Non-sequitur tinkering, you could call it. It’s sort of like working on your car, or the Hackintosh hijinks discussed in the Salad Days episode. (Or making a bunch of stew even though your wife doesn’t want any. Like I’m doing right now.)
Jekyll is a nice, lean static blog generator. However:

  • I already have this blog looking the way I want, and I don’t want to painstakingly recreate it.
  • There’s also that should Death Mountain leave a web host that uses WordPress, Bravest Ever would leave it, too, and I don’t want to mess with the way Katt does posts (via WordPress).
  • Also, I liked posting using the WordPress iOS app the one time I’ve used it so far.
  • I like WordPress’s thorough cross-linking by dates and categories.

I wanted to keep the WordPress design and input methods while also having a static site. Maciej, the Pinboard guy, said something about this in passing quite a while ago.

You can use a program like wget or curl to generate a flat HTML version of your website from this local version, and then upload these files to your public server to share them with the world.

Here’s how to do this in practice:

First, get a copy of your WordPress blog running locally.

  1. Transfer the directory containing your instance of WordPress (usually named yourblog.com and containing index.php and various wp-* subdirectories) to your local machine.
  2. Transfer your database entries to your local MySQL instance. Export the database named after your WordPress blog. Some hosting services provide a web-based way to do this; but you can also use a shell command like mysqldump -u[username] -p [db name] > mysql.dump. To import that file into your local MySQL instance, use mysql -u[username] -p [db name] < mysql.dump or the equivalent. (I use MAMP to run Apache, MySQL, and PHP locally. It’s simple.)
  3. The tricky thing about running WordPress locally is that it uses a stored value to determine its base URL rather than using relative paths. e.g. So, if “WordPress Address” and “Site Address” in the WordPress dashboard (or in wp-config.php) is set to http://death-mountain.com, it will point all the links to other parts of the site to something based on http://death-mountain.com rather than on http://localhost.Now, you can set those properties to http://localhost. Then, all the links will work on your local instance of your blog, however, when you take a static snapshot of your site, the links will be pointing to localhost, which is no good.So, you need to keep these WordPress properties pointing to your real blog URL but get requests for http://yourblog.com on your local machine to go to localhost. So, add an entry to your /private/etc/hosts file like so: 127.0.0.1 yourblog.com.

    If you’re on Lion, make sure you put that above the “fe80::1%lo0” line. And don’t forget to flush your DNS cache afterward. On OS X, dscacheutil -flushcache will do it.

    Now, you will be able to run your WordPress blog locally, using your real URL. You can shut down your Internet connection to make sure it’s working.

    Oh, also: You will need to run Apache (or whatever web server you use) on port 80. To do that, it needs to run as root, so start it with sudo.

  4. Now, use wget to get a static snapshot of your site. Unlike running WordPress locally, wget is much less tricker. Just go to a clean directory and run:
    wget -m and robots=off http://yourblog.com
    Within seconds, you’ll have your whole site as static files. It will be from the non-admin’s perspective as well, so none of the admin stuff will be there.
  5. If you want, that can be the end of the line. When you want to post, just start your MAMP/LAMP stack, write your post, run wget, then upload the files wget gets to the server.I’d prefer not to upload the whole thing, every time, though, so I use git to handle just sending the diffs. It also has the side benefit of letting me revert to specific versions, plus everything else git does. If you are not already familiar with git, though, this is probably not worth it.I’m already git-centric, though, I created a git repo in the directory in which I put wgets output: The static snapshot. Then, I followed this awesome howto to set up a way to update the web site just by pushing with git. (If you’re using github for hosting, you can just push straight to github and skip all that.)

    So, my update workflow goes like this:

    1. Start MAMP, if it’s not already running.
    2. Go to http://myblog.com (which will actually be my local instance of the site) and post.
    3. Run wget in my static site directory. (Which is a git repo.)
    4. Commit the changes in git.
    5. Push the git repo to the web host.

That’s it! I’m posting with this method now. It’s two extra no-brainer steps. It’ll serve up faster, and I’ll be able to move web hosting easily now. It’s not the most detailed explanation, but hopefully, you get the idea. I’d go into further detail, but my stew is almost done.


Leave a Reply

Your email address will not be published. Required fields are marked *