[wp-hackers] Nasty get_option()/get_settings() bug

Ryan Boren ryan at boren.nu
Thu Jan 12 01:06:38 GMT 2006

On Wed, 2006-01-11 at 18:18 -0500, Mark Jaquith wrote:
> On Jan 11, 2006, at 8:56 AM, David House wrote:
> > On 11/01/06, Mark Jaquith <mark.wordpress at txfx.net> wrote:
> >> So what we need to do is come up with a way to discriminate between
> >> "option isn't in cache" (and therefore, make the query) and "option's
> >> non-existence has been cached" (and therefore don't make the query,
> >> because we know it doesn't exist).
> >
> > The way it used to be done is have a seperate cache,
> > $cache_nonexistantoptions or something, that stored the names of
> > options that don't exist. This was checked before querying the DB. Is
> > this not done now?
> No, this is not currently done.

Non-existant objects are cached per request within WP_Object_Cache.
Look at WP_Object_Cache::get() and ::set().  However, false is returned
if the object is non-existant.  This means that we will avoid multiple
attempts to find the cache file for a non-existant object, but
get_settings() will still try to hit the DB every time.

A magic value might work.  We need to avoid using NULL to mean "not
there" since $wpdb returns null for empty strings -- a valid value for
some options.


More information about the wp-hackers mailing list