Monthly Archives: March 2012

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.


A new kind of work

I completed my first week as a full-time independent developer. Things I learned:

1. It’s easier to get solid concentration going in the morning if I work somewhere outside of the home. Concentrating in the afternoon is not as hard at home, especially if I have momentum from the morning. I still need to learn how to get going in the morning at home, though. Coffee shops cost money.

2. Having a broad plan for each day of the week helps. This way, you don’t spend too much time thinking and re-thinking what you should be doing. (I had guessed as much from my experience with meal planning, which severely reduced our decision fatigue.) You also cut career existential doubt out of the loop completely.

3. I can kill ideas that are unlikely to work by starting to plan out the work for it. It might not be a true death, though, as they keep popping back into my head. But at least I didn’t spend time on them.

4. I thought I liked listening to podcasts and music while working, but that turns out to only be for work that I have to push myself to start. I think they distract me from my resistance to starting. If I don’t have a problem starting, though, as is the case with a lot of what I worked on this week, podcasts and music are just distracting. The sounds I’ve enjoyed the most this week are near-silence and background chatter that’s busy enough that I can’t distinguish individual conversations.

5. It is really good to have an “American dream”-style weekend in which you don’t expect to do much work and thus are not disappointed when you don’t. When you’re a part-time indie, concerns over whether or not you really are getting as much as you should out of the weekend hover over you like a cartoon stink cloud. They’re a lot easier to dismiss when you know you’ve put in a solid week.