UNDERDOG of PERFECTION

I was beyond dismayed tonight to load up my browser and discover that my website, for whatever reason, just wasn’t working. Firefox would just bring up a completely blank screen. Safari returned a strange error:

Safari can’t open the page “http://room34.com/”. The error was: “Operation could not be completed. (kCFErrorDomainCFNetwork error 302.)” (kCFErrorDomainCFNetwork:302) Please choose Report Bugs to Apple from the Safari menu, note the error number, and describe what you did before you saw this message.

Uhh… OK.

Needless to say, it’s not something I’ve ever seen before, and if Google is any indication, (almost) no one else has either.

After inspecting my files and my data tables to see if anything had been altered (i.e. hacked — and no, it hadn’t), and watching The Colbert Report, I decided I had no choice but to confront the rat king and start stepping through all of the nested include files that comprise the WordPress application, hoping to find the exact point at which the whole thing was going kerblooey.

Eventually I did manage to find the precise line in the precise file where the site ceased to return any output to the browser. It happens to be line 20 in wp-includes/taxonomy.php, which goes something like this (minus the insistent tendency of WordPress to automatically insert smart quotes everywhere):

$wp_taxonomies[‘link_category’] = (object) array(‘name’ => ‘link_category’, ‘object_type’ => ‘link’, ‘hierarchical’ => false);

Having abandoned efforts to further dissect the innards of WordPress, I tried commenting out the line. No luck. Next I tried just sticking a return; at the top of the file, essentially scuttling everything it does. That did display the page, but without the functions in this file it was so riddled with error messages as to be unusable. Next, I returned to line 20 and emptied out that array it creates (commented it out, to be precise), leaving, in essence:

$wp_taxonomies[‘link_category’] = (object) array();

And, whaddayaknow… it freakin’ works! In fact, on cursory perusal of the site, I don’t even see any problems, so I’m not sure where this particular subarray gets used, or whether my own idiosyncratic taxonomic structure even needs it. And I’m sure within approximately 24 seconds of posting this entry, I’ll discover it. But for now, things seem good… although I hate having to settle for a “solution” like this, especially given the effort it took to pinpoint the problem.

Update, May 30, 2008: I was informed by my hosting provider that last night they performed a PHP upgrade, which seems to have been what precipitated this problem. So perhaps I have discovered a conflict between PHP 5.2.6 and WordPress 2.5.1.

Update, June 2, 2008: After working briefly with my ISP on this issue, they have modified a configuration setting on the server to solve this problem. Here’s what they had to say about the change: The server was previously configured to support PHP4 backwards compatibility via the following directive:

zend.ze1_compatibility_mode 1

They’ve removed that compatibility mode setting in the configuration for my virtual host, as such:

zend.ze1_compatibility_mode 0

This change on their part has solved my problem, as I have now reinstated the original WordPress code in taxonomy.php and the site is functioning properly.

Not to be confused with stinky feet, sticky footers are a CSS technique whereby a page footer always appears at the bottom of the page/window, even if the content of the page isn’t tall enough to fill the window completely. (For you HTML-phobes out there, normally all of the content on a web page flows vertically one element after another, meaning that your page “footer” can potentially end up in the middle of the window, with a bunch of blank space below it, if your page content is too short. Not to be confused with Too Short.)

I have seen sites whose owners had solved this problem, but as it’s never really been an issue for me (since I never have too little content to fill a page, I guess!), I haven’t bothered to dig into the solution, until today, when I needed to for work.

The Man in Blue (also known as Australian author and self-identified “web technologist” Cameron Adams), has posted an elegant solution, which has also been floating around in various forums.

It goes something like this… season to taste:

html {
  height: 100%;
}
body {
  height: 100%;
}
#nonFooter {
  position: relative;
  min-height: 100%;
}
* html #nonFooter {
  height: 100%;
}
#footer {
  position: relative;
  margin: -7.5em auto 0 auto;
}
/* A CSS hack that only applies to IE — specifies a different height for the footer */
* html #footer {
  margin-top: -7.4em;
}

As you probably know if you’ve read any of my writings here, or have by chance listened to my album, Unnatural Disasters, I have a morbid fascination with North Korea’s never-to-be-completed Ryugyong Hotel. So I was pleased to see that this wondrous failure has achieved a new level of notoriety, having been designated earlier this year by Esquire magazine as “The Worst Building in the History of Mankind.” Sweet. Like the best Onion articles, it’s worth reading to the very last line, but since I can never hold back on a punch line, I’ll save you the trouble: “[The Ryugyong Hotel] is the closest humans have come to building a Death Star.”

Perfect!

Last Friday night I spent a few hours playing around with some new musical ideas. I worked on some acoustic guitar parts for some earlier songs (including a possible re-recording of my 2003 track “Tai Chi for Oafs”), and I also worked on a couple of brand new ideas.

These may never see any further attention than what they got that night, and they’re presently fairly repetitive, but that’s why they fade out mercifully quickly. Enjoy! (Or not.)

Don’t Limit Me, Steve!
The working title of this track is aimed squarely at Mr. Jobs. As much as I love all things Apple, especially GarageBand, I do find it aggravating at times that the software makes you select a time signature, tempo and key before you can create a new song project. It makes it difficult to just play around with ideas because if you want to change any of these attributes, it permanently alters the playback of any tracks you’ve already recorded. I’ve retaliated by creating this song with an unnatural 11-bar chord progression and a bass riff that strangely hits a major 6th where the listener (myself included) would normally expect to hear a minor 7th.

[audio:http://blog.room34.com/wp-content/uploads/underdog/steve.mp3]

Mellotronic
Just a mellow electronic thing. And of course, given the name, I had to put some Mellotron in it.

[audio:http://blog.room34.com/wp-content/uploads/underdog/mellotronic.mp3]

What’s even more extremely current than “bleeding edge”? Well, whatever it is, I’m not it. But I still try to keep my software as current as possible, and that includes updating WordPress whenever a new version is out. Most of the time, the difference is negligible, of course. Other than the major transformation of the admin interface with WordPress 2.5, very little actually changes as far as your site appears to the outside world. Which is good, for the most part, because you don’t really want unexpected changes on your site just because the underlying software is changed. It should all keep working just like it did before.

And there’s the problem: usually the only things I notice that are different when I run a WordPress update are things that are broken. That, and the fact that it’s a major pain to have to update the entire file set whenever a few changes are made. (It would be easy if I had terminal access to my server so I could upload the tarball, but no dice. I have to upload all n-thousand files individually.) So far I haven’t been able to find a reliable source listing exactly which files are modified from version to version.

That aside, what really frustrates me is when I do an update, like the 2.5.1 update that was released last week, and discover that none of my navigation works anymore. I still have no idea exactly what they did, but the old URL rewrites I was using — /%category%/%post_id% — crapped out. It seems like the %category% variable isn’t supported anymore, but I can’t find any documentation of that kind of change (nor can I comprehend the logic behind it, if it was in fact intentional).

Anyway, I discovered along the way that pretty much any of the rewrite schemes (at least, the 3 or 4 standard ones) seem to work, regardless of the one you’ve chosen as your “real” scheme. This makes sense because if you change the scheme, old links from other sites will still work. But my chosen custom scheme does not, anymore. So after some angry fiddling around, I settled on one of the standard schemes that’s almost like what I was using before, and everything seems copacetic, for now.