[wp-trac] [WordPress Trac] #28664: wp_load_alloptions() fails to set object cache when persistent alloptions cache is "0"

[WordPress Trac]

#28664: wp_load_alloptions() fails to set object cache when persistent alloptions
cache is "0"
-----------------------------+------------------------------
 Reporter:  danielbachhuber  |       Owner:
     Type:  defect (bug)     |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Cache API        |     Version:
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:
-----------------------------+------------------------------

Comment (by nacin):

 We could do a wp_cache_set() if $alloptions is !== false in
 wp_load_alloptions(). (The proper way to do this would be to use the
 &$found argument in wp_cache_get(), but it's not reliably in cache
 backends and is really only useful for crazier environments like
 WordPress.com.)

 That said, I've never seen another report on this, and this kind of cache
 poisoning is really tough to account for. I'd rather not sweep the problem
 under the rug if only because if this is happening to you for alloptions,
 it'll probably happen for other keys eventually, and this is a slippery
 slope.

 If $alloptions_db ends up being an empty array, and an empty array gets
 passed to wp_cache_add(), is it possible to get back a 0 with these
 backends? I assumed not, but I'm not sure. (And if so, are your queries
 failing? We suppress DB errors there and it may be hiding a problem.)

--
Ticket URL: <https://core.trac.wordpress.org/ticket/28664#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform