[wp-trac] [WordPress Trac] #15881: wp_cache_get generates fatal error

[WordPress Trac]

#15881: wp_cache_get generates fatal error
-------------------------------------------------+-------------------------
 Reporter:  pixelgeek                            |       Owner:
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
Component:  Cache                                |  Review
 Severity:  critical                             |     Version:  3.0.3
 Keywords:  $wp_object_cache, wp_cache_get       |  Resolution:
  cache.php                                      |
-------------------------------------------------+-------------------------

Comment (by donncha):

 The problem is plugins (and Supercache here) using the caching system by
 accident *after* the caching object has been destroyed by PHP. Versions of
 PHP newer than 5.2 or so destroy objects during shutdown before the code
 in any shutdown callbacks runs.

 I accidentally used get_option() when I called is_front_page() in the
 output buffer callback. It worked fine on my server but on other servers
 it obviously doesn't. That's why I didn't catch it before it was released.

 This bit me in another way too, the plugin used a meta object to describe
 certain cached files. On some servers those cached files weren't served
 correctly and it took a long time to figure out why. I blogged about this
 ages ago and can dig up the post if anyone is interested.

 Anyway, the problem is fixed now in trunk by caching out output of
 is_front_page() on init (or template_redirect, I can't remember) and using
 that cached variable.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/15881#comment:4>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software