LIEBERMAN CAMPAIGN CRASHED OWN WEBSITE: “The server that hosted the joe2006.com Web site failed because it was overutilized and misconfigured.” That’s like when people send me a link to their underpowered WordPress blog, then it produces a “Database Error” message when too many people try to actually read it. I hate that. (Yeah, this happens elsewhere sometimes, but low-power WordPress blogs seem particularly susceptible.)

Until WordPress version 2.5, a failed database would generate error screens like the one below:

Note the nifty WordPress branding that appears at the top. Thanks to that, countless Diggers, Slashdotters, and the like began to associate WordPress with failure. This is a post hoc fallacy of course: plenty of sites that buckle under the loads brought by Digg are not powered by WordPress, and many WordPress sites that survive a slashdotting are powered by WordPress. But in both of those cases, it’s not obvious; no giant logo greets you to say “WordPress powers this site, which is staying up just fine!”

In my opinion, WordPress version 2.5 solved this problem the right way, by adding a non-branded database error message:

Other people, including both WordPress proponents and opponents, think WordPress lacks something by not allowing all of its users to handle heavy database stress. I’m not so sure.

Flexibility is a large part of what makes WordPress such a great application to write code for. If you let plugins do just about anything imaginable on every page load, there’s a good chance that a small host’s database won’t be able to handle all of that in the face of a slashdotting. And that’s okay. The vast majority of WordPress users won’t ever be slashdotted, and so they don’t need the extra complication, potential server problems, and plugin incompatibilities that built-in caching would produce.

If yours is the type of site that’s going to suffer under the Digg effect, then you can install one of the caching plugins to help you endure, or you can count on superior server resources. Everyone else will be just fine.

Actually, the development version of WordPress has been implementing a new “prepare” method of the WordPress DB class. The “prepare” method uses vsprintf to makes sure sure, for example, that integers are truly integers, which should accomplish the same thing as Kierznowski’s proposed escape_int and escape_str methods.

And WordPress once actually did use mysql_real_escape_string(), over two and a half years ago. The problem is that WordPress’s minimum requirements specify only that one use PHP version 4.2 or newer. However, mysql_real_escape_string() was not introduced until PHP version 4.3.0, so WordPress had to rely on an alternate way of escaping queries, one that apparently has caused some trouble, so the whole thing was bypassed. However, PHP 4.3.0 functions have crept into development WordPress already, so it’s likely by the time of the next release (version 2.5) in the spring, that the minimum version will have increased and WordPress will be free to use mysql_real_escape_string.