Learn how to publish content created in Google Docs to Wordpress.More
You’re searching your blog for spam for the fourth time in the last few days. Not only can’t you figure out how the spammer keeps getting in, you also can’t figure out what they’re trying to sell with the mangled English in their posts… hand bags? sports drinks? Something with too many consonants and not enough vowels?
If only your web site had some kind of “black box” so that you could find out what they’re doing to post the spam.
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.
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.
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.
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 romkey.com 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!
I have a bunch of half-written things that I haven’t finished because I haven’t been happy with the state of cross-posting between this blog and Livejournal and I haven’t really had the time to deal with fixing it. … If you’d rather that I didn’t cross-post, or didn’t cross-post everything, let me know and I’ll see what I can figure out about limiting it. … And for some reason my web server is uncooperative about providing me with useful errors in its logs (yes, I’ve double-checked the Apache configuration… it’s … something else). … LJ-XP has changed hands once or twice, and some of the older versions don’t point to the correct location for the current plugin (which is http://code.google.com/p/ljxp/ ).More