I also turned on HTTP compression, which in WordPress is as easy as clicking a checkbox. It not only saves you bandwidth, but users get your pages served quicker, since the bottleneck is bound to be their bandwidth, not their browser’s ability to decompress.

We’ll see how it goes. Bandwidth has been growing recently: January 2.8Gb; February 2.7Gb; March 3.4Gb. It’s not at ludicrous levels, but if it keeps climbing, I’ll end up paying more for the hosting. Hopefully this will help bring it back down.

Update 8:40pm. First thing I notice is that when reading the feed from within the Feedburner site, it doesn’t treat relative paths to images properly. I guess I’ll have to put absolute paths, ‘cos at the moment in the previous post it’s trying to load http://feeds.feedburner.com/files/2007/mediagate-mg35.jpg instead of http://www.geekrant.org/files/2007/mediagate-mg35.jpg. I wonder how it treats relative links?

Bad stuff happens. We all know that. Even if it’s the most reliable setup ever. But there’s some major factors in determining what’s acceptable:

Frequency — If it’s happening too regularly, then there’s a reliability problem. They need better hardware, better software, whatever it is, needs to be fixed. Cam reckons it’s the second time in a few months.

Response — Obviously, you want a quick response, and a quick (and reliable) solution. There’s also sorts of monitoring tools out there these days. Typically anything like a full outage should be known about within minutes. A reputable web host will have substitute hardware ready to switch-on and go just as soon as that nice recent backup is restored.

Communications — Any third party like this has to keep the customer informed. There’s no excuse for not doing so. SMS alarms, emails, phone calls, whatever. (I wrote about alarms recently for my work blog.)

BTW, Cam’s also having troubles with his iPod… or more accurately, Apple’s 90 day warranty on replacement units.

I reckon he’s jinxed, myself.

The way to do it is to hack your hosts file. Once the new server is running and WP is setup on it, find your hosts file and add an entry to the new server. On Windows, this is the c:\windows\system32\drivers\etc\hosts file.

Chuck in a line that says contains your new server’s IP address, and the hostname. Something like:

192.168.0.1 www.evision.com.au

(Whoopsie, real-world example with a fake IP. The new evision site is going live Real Soon Now.)

Save, then away you go. You can see the new site and tweak to your heart’s content, but nobody else will be able to see any of it until you re-delegate.

The catch? It probably won’t work from behind corporate networks, where your computer uses a proxy.

If the site goes down in the next day or two, you’ll know why. Best wishes to those in the affected areas.