[Plugin: WP Super Cache] Call to a member function get() on a non-object in cache.php

I don’t think this is related to the wp-super-cache plugin. It doesn’t use the object cache at all.

Same problem here…I got a blank screen with the same error in the logs. The plugin has otherwise been working perfectly.

Renaming advanced-cache.php in the wp-content folder me get back in then I logged back in to admin, went to the plugin page (where it errored about the advanced-cache.php not being there), renamed the file back and then it was right again…

Cheers,

Chris.

We have also started to get this exact error in the log since enabling the plugin. I haven’t been able to trigger it myself. I’ll see if I can get a backtrace to see what it happening.

Ok, that wasn’t altogether easy.

Backtrace is:
wp_cache_ob_callback, current_time, get_option, wp_cache_get

The problem here is that it is executed before the $wpdb object is set up.

Meaning it has to be from the early include of advanced-cache.php.

Not knowing the cache code a wild guess might be it somehow gets called early through the cron code?

I think I know where it’s happening.

current_time() is called in the callback. That’s called during PHP’s shutdown process. Unfortunately the shutdown process sometimes/at random kills off the objects used in the process before the script is actually finished working.

It’s a PHP bug, and I read it was described as a chicken and egg problem.

I have a feeling this wasn’t the case in earlier versions of PHP4, and only started to become a problem with PHP5 and later PHP4.

It’s the same reason that gzip headers were sometimes not recorded in the meta files and I had to add a hack in wp-cache-phase1.php to add them back in. I literally watched my debug log as the headers were added to the meta object, and then somehow disappeared by the time the plugin was due to write them out. Very weird.

Huh, weird.. ??

The server does use php 5 (5.2.4).

I’ll replace current_time() with a plain gmdate() and see if I’ll get new errors from something else.

Any solutions to this yet? I got the same error after upgrading to the newest version of super cache yesterday. I have a heavy traffic site so i am eager to fix it.

Ok, I can report that just changing current_time() to gmdate solves (or hides anyway) the problem for me. Before I got an error every hour or so. Now 24 hours without trouble.

So the rest of the objects seems to survive long enough.

It is an inelegant hack and doesn’t solve whatever the root of the problem is.

What I did was changing current_time() in wp-cache-phase2.php : wp_cache_ob_callback() to gmdate(‘Y-m-d H:i:s’).

If you care that the time is printed correctly in the html comment it should be: gmdate(‘Y-m-d H:i:s’, (time() + (<your gmt offset> * 3600)))

johanee – thanks for that. I’ll make those changes, but I think the cache needs to use a different way of executing the callback. During shutdown is too late as it causes so many problems ??

johanee – can you grab the development version from svn at https://svn.wp-plugins.org/wp-super-cache/trunk or the zip file development version on the download page. (Should update in the next 15 minutes)

I removed the PHP shutdown registration, instead calling it from the output buffer callback. Hopefully the output buffer gets processed early on in the shutdown!

One of my sites had this bug (the other uses memcached and seems to be immune). The development version fixes this bug there so I’d like to hear if it works for anyone else too!

Installed files from zipped development version, will report back tomorrow.

Sorry, fails in same way:

wp_cache_ob_callback, wp_cache_get_ob, current_time, get_option, wp_load_alloptions, wp_cache_get

I don’t think this is a PHP issue.

/includes/cache.php (object-cache) registers a shutdown callback before supercache does. They get called in the order they are registered, so the object-cache dies before supercache.

It follows then that function calls from the supercache shutdown callback that access the object-cache (like current_time does via get_option) will fail.

Murmatron 2 – that’s interesting. It’s strange that it only happens some of the time, but I’ll see if I can move the ob_start() up higher in the process..