Looking through the code, I find:

Browser upgrade banners. People using old versions of Firefox (currently 1.5 or older) or Internet Explorer (currently 5.5 or older) get an “Upgrade to Firefox 2″ banner instead of the thumbnail of the current issue of the comic. This is just as easily done with JavaScript—and is done with JS elsewhere on the site. (I used to make some minor adjustments for other versions of IE, but I converted them all to conditional comments a while back.)

Last-modified date in the footer, pulled from the actual file. I’ve already got a script to update this in the static files, so it’s just a matter of adding it to my general update script. A two-minute, one-time change and I’ll never notice the difference.

Latest posts from this blog. Probably better done with an iframe, or maybe using AJAX. Drawback: either method would mean an extra request from the client. On the plus side, repeat visitors would be able to re-use the rest of the page, and only download the 5-item list.

Unique-per-day spamtrap addresses, hidden where harvesters might pick them up. But only a few of them still accept mail and feed it to filters. Mostly, they just waste spammers’ resources. I could easily either get rid of them or change the script to generate a new address with each update instead of each day.

So really, there isn’t much stopping me from using a static file for the most-viewed page on the site, with all the attendant savings in system resources, bandwidth, etc.

On the other hand, I keep contemplating switching to a database-driven system for the whole thing, which would make any changes now meaningless. But since I’ve been thinking about that since around 2000 or so, and haven’t changed it yet, that’s not exactly a blocker!

Update (March 30): I’ve made the conversion to a static file. The blog posts and browser upgrade banners are now done client-side (and run after the rest of the page is loaded), the last-modified date is part of the pre-processing script, and I just removed the daily spamtrap addresses. Now to see whether it actually improves performance.

Last Friday saw the release of PHP 5.2.4, on the Friday before—in the US, anyway—a 3-day weekend. This morning Apache released security updates for all three supported branches of their webserver. And this evening—yes, Friday evening—WordPress 2.2.3 came out.

Which reminds me, I’m going to have to start looking at the betas for WordPress 2.3. I think it’ll be a good time for a redesign. Maybe pick a new theme and tweak that one, maybe try my hand at actually designing one. I wonder if the new tagging system can import Bunny’s Technorati Tags.

Update: Actually, today’s posts seem OK. The plugin seems to just send the blog ID and post ID. I’ve been trying to figure out how the central server is retrieving the permalink and title. It doesn’t look like Bad Behavior is blocking it. And it doesn’t seem to be using the RSS feed, since posts that are still on the front page (and presumably still in the feed) are also showing up as numbers. *grumble*

Update 2: I just noticed that all of the number-only posts show the same placeholder graph showing “Region A” vs. “Region B” for 2003-2005.

Update 3: It’s a problem with WordPress’ XMLRPC interface, and affects other uses (like connecting with Flock). I’ve got a workaround, though (see comments).

Update 4 (May 10): Thanks to the pingback below from dot unplanned, it’s confirmed to be a bug in PHP 5.2.2. With any luck, the workaround will cease to be necessary when the next PHP bugfix is released.

After fixing it manually—again—I’m still getting broken pages and seeing this in the error logs:

PHP Fatal error: Call to a member function get_row() on a non-object in /path/to/wp-includes/functions.php on line 211

Is it just my imagination, or does no one at WordPress actually test it with current versions of PHP?

Update: Switched back to WordPress 2.1 and it’s working again.

Update 2: For some reason, diffing a plain 2.1 against a plain 2.1.1, then applying the patch to my site, seems to have resulted in a working site, even though uploading the new files and manually fixing things didn’t. Presumably I have another manual fix in there that I didn’t label.

Update 3: I’ve re-uploaded the new files, which resulted (as expected) in a broken site with the fatal PHP errors on get() in cache.php on line 32. So I re-applied the manual fixes from that bug which wasn’t actually fixed in 2.1.1. And now it seems to be working.

I’m still seeing the errors on get_row() in functions.php, but they don’t seem to be associated with broken pages. A little further digging and they seem to have started on Monday, with the upgrade to PHP 5.2.1. Spot checking the error times against the access log suggests it’s only happening with hits from bots, so there may be something going on with Bad Behavior. Update 4: Strike that, it just happened on the preview for this post. GRRRR.

Update 5: Found the problem! I’d forgotten the other change I made on Monday, which was to enable WordPress’ internal cache in wp-config.php:

define(’ENABLE_CACHE’, true );

That explains why it would seem to work at first, and then stop working. At first, WordPress would be pulling info from the database, but then it would start pulling it from the cache instead… and something about the way that functionality works doesn’t agree with PHP 5.2. The first instance of the error coincides closely with the timestamp on the config file.

So the old fix still works…unless you’re using WordPress’ internal data cache.

Update 6: On a related note, I tried Reiner Saddey’s fix for getting WP-Cache to remember the content-type on feeds, but it had the same problem my fix did, which was to break conditional gets (it would send a full 200 OK response, with the entire feed, instead of just a 304 Not Modified code). And with something that gets requested as often as a feed, you really want conditional gets to work.

Update: It looks like something in my setup disagrees with the combination of PHP 5 and WP-Cache 2. Pages were turning up blank the first time they were loaded, then perfectly OK the second time. Oddly, it was working fine under PHP 4.4, MySQL 5, and WordPress 2.

<?php code goes here ?>

On some servers—maybe even your own—you can shorten this to just the opening <?. The following line in php.ini will disable this “feature,” and many web server administrators do so to simplify things like generating XML with PHP:

short_open_tag = Off

When this option is set, PHP will ignore <? and assume it’s simply part of the template… along with all the code following it. If you’re lucky, it means a bunch of PHP code gets sent to the web browser. If you’re not lucky, it results in invalid syntax, and PHP grinds to a halt, spitting out a blank page and a PHP Parse Error.

So please make sure you always use the full opening tag so that your plugin will be compatible with everyone’s system. If you run your own server, set that option in php.ini so that if you miss one, you can catch it before you post it.