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.