Tech Note: Cloudbusting

My blog runs on a piece of software called WordPress. I love WordPress; it’s well designed, easy to use, easy to maintain. It’s good for serving blogs but it’s also great for creating small simple web sites. I’ve recommended it to a lot of organizations for their web sites, and I’ve helped several of them set those sites up.

That said, WordPress has a reputation for falling over under heavy load. It creates each page on demand, which is very taxing compared to just having the pages sitting there ready to go. This hasn’t been a problem for me given that my site’s not very active but I’m about to do something which (if it’s successful) will bring in a lot of traffic for a short period of time, and I don’t want the site to fall over during that time. I don’t want it to neilwebfail.

There are a number of ways to try to fix this problem. I’m currently trying out a caching plugin for WordPress called W3 Total Cache. W3 Total Cache uses a variety of methods to improve the performance of a WordPress web site, from Javascript and CSS combining and minifcation to database and page caching to using a CDN (Content Distribution Network).

The CDN is the most interesting part to me. With a CDN, you put files on servers (the currently hot “cloud”, though people have been doing this since before the cloud label existed) designed to get them to browsers as fast as possible. The servers may replicate the files so that they are as close (in a network topological sense, not a physical sense) as possible to the browsers that are trying to reach them.

I’ve been interested in using a CDN for some time but none of the projects I’ve been working on have needed one. They’ve all been low load, local sites. But a CDN may help my blog survive a #neilwebfail, so this is a great change to try it out.

I’ve been using Amazon’s S3 storage for some time for other projects. They also offer a service called Cloudfront which turns S3 into a CDN. W3 Total Cache knows how to work with Cloudfront, so this is what I’m turning on as of now. It looks like W3 Total Cache only uses Cloudfront to store media, CSS and Javascript files, not the actual web pages itself, which it will still aggressively cache on the server. That still helps off-load traffic from the server and helps deliver those files to browsers much quicker.

When this experiment is done I’ll report back on how it went (assuming I get to really test it the way I’m hoping to). A great thing about Amazon is that they only charge for actual use, so if I don’t see a burst of traffic I won’t be paying for service I’m not using. I’m very curious to see how much it will actually cost to survive a burst.

Two tools for helping with setup:

1. Panic’s Transmit (web site, with a free trial; Mac App Store) application for MacOS X. Besides being a very handy (S)FTP application, Transmit can talk to Amazon S3, so you can inspect and manually update what’s being stored there if you need to. If you’re not willing to pony up for Transmit (and in my opinion, it’s well worth the cost), you try Cyberduck, which is donation-ware (and also available through the Mac App Store).

2. Firefox’s Firebug and Chrome’s debug console. Use Google PageSpeed with them to see how your site is measures up.

Nutrition Labels for WordPress

I’ve just released a plugin for WordPress, wp-nutrition-label. It provides a WordPress shortcode which generates an HTML FDA-style nutrition label. For instance,

Nutrition Facts Serving Size 1/2 cup Servings 2
Amount Per Serving
Calories 87 Calories from Fat 27
% Daily Value*
Total Fat 3g 4%
Saturated Fat 1g 5%
Trans Fat 0g
Cholesterol 0mg 0%
Sodium 250mg 10%
Total Carbohydrate 10g 3%
Dietary Fiber 0g 0%
Sugars 0g
Protein 5g 10%
* Percent Daily Values are based on a 2,000 calorie diet. Your daily values may be higher or lower depending on your calorie needs. wp-nutrition-label

The label is styled to scale but doesn’t yet scale well. Some elements of it work well but the “Nutrition Facts” text sometimes scales poorly. I’m looking at ways to improve the way that the label scales.

I’m also working on adding more nutrients (vitamins and minerals) to the label but haven’t quite decided on how to do it yet.

This is the first piece of software I have publicly released in a very long time. It’s quite likely the first piece of GPL’d software I’ve ever written – most of the software that I have publicly released (MIT’s PC/IP, in particular) was written pre-GPL. It’s ironic that it’s written in PHP, one of the my least favorite programming languages ever, though as much as I dislike PHP I have a great deal of respect for WordPress.

How to Quote a Shortcode in WordPress

WordPress offers a handy mechanism called a “shortcode”, which is a kind of macro. Shortcodes are supplied by WordPress itself and by plugins that extend WordPress’ functionality.

You use a shortcode by simply writing it in your post or page enclosed in square brackets, ie:

When you’re writing a post about a shortcode in a plugin you’ve written and are using in your web site, you’ll run into a problem where you will want to show examples of the use of the shortcode, but the examples trigger it.

You can quote the shortcode by doubling up on the opening and closing square brackets, ie:

I didn’t know this and didn’t need it until recently and was agonizing about it until I found how to do it.

Eating My Own Dog Food

For a while I’ve been advising people who need simple web sites to use WordPress. Not just people who want to blog, but people who need a very simple site with just a few pages. The reason I’ve been suggesting they use WordPress is that it’s easy to update pages (WordPress has a built-in WYSIWYG editor and automatic menu building), simple to extend and change the appearance of, and easy to maintain. Because you can keep drafts of your work in WordPress itself and it runs on the server, it also doesn’t matter where you work on it from, so you don’t have to worry about business computer versus home computer.

A downside is the prominent security issues WordPress has had of late (though the folks behind WordPress are prompt in fixing issues and clear about letting people know they need updated software). I want to be clear that I am in no way suggesting being lax about installing security updates, but it is true that a WordPress install that’s basically read-only – no user commenting and no remote posting enabled – is much less likely to suffer a break-in than a common blog would be.

I haven’t touched my web site in years. I started a blog at and until now hadn’t posted to that in almost a year.

My site consisted of several poorly laid out pages that were quite out of date, written using Perl’s HTML::Mason package. I quite like HTML::Mason but it was overkill for what I was doing, and I’d like to get mod_perl out of my web server.

So I’m going to eat my own dog food and move my site to WordPress. In fact, I’ve just remapped things so that the blog is now the site, and I’ve switched to using WordPress 3’s standard theme, TwentyTen, with some tweaks. Because I’m also trying to get over not-invented here syndrome. (If you subscribed to the blog at the old address you don’t need to change anything; it should just keept working.)

I’ll move over pages from the old site as I have time to rewrite and update them.

Mmmm, dog food. Not as bad as it sounds!