WordPress Broken on PHP 5.2 Again

NOTE: This article is out of date and likely obsolete.

Update: It’s only broken in combination with WP-Cache (see Update 5 below).

Upgraded to WordPress 2.1.1. Supposedly should’ve fixed the PHP 5.2 problems. In reality, they’re worse unchanged. Bug 3354 is marked fixed, but it seems to have only been fixed on the 2.0 series.

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 7: Saddey comments:

As far as Update 6 is concerned, yes, that’s what I would have expected from the WP-Cache sources. I promise to have an in depth look into the 304 Not Modified till the end of next week. I just love Ricardo’s WP-Cache plugin, it’s well structured and I don’t think that it will be very hard to have it return the proper 304 response.