Possible bug in get_option()

  • bmaddy

    (@bmaddy)


    15 years, 7 months ago

    I’m using the NAVT plugin (version 1.0.26) with WordPress MU (version 2.6.1).

    NAVT contains the following line of code:

    add_option($key, $value, $description, 'no');

    Later in the code, it calls get_option and doesn’t get anything back. If I change the above line to this it works fine:

    add_option($key, $value, $description, 'yes');

    From what I can tell, there doesn’t seem to be anything that gets options from the database that aren’t autoloaded at the initialization of wordpress. I would think it would be in the wp_load_alloptions() function because that’s where wp_cache_set() is called in that file. All it has in there is a query that searches only for autoloaded options and if doesn’t find any, it grabs all options. It doesn’t seem to handle the case where there are some autoloaded options and some that should be loaded later.

    I’m not terribly well versed in wordpress code, so I might be way off on this. Also, I’m not sure if it’s a WordPress or WordPress MU problem. It doesn’t seem to be a NAVT problem though.

    If anyone has any thoughts on this I’d love to hear them!

    Thanks,
    Brian

Viewing 3 replies - 1 through 3 (of 3 total)
  • dgodot

    (@dgodot)

    15 years, 7 months ago

    I’m having a similar problem with get_option() in WPMU 2.6.

    From within a plugin I’m working on, get_option() works fine when called from the admin, but not when called from blog pages. Like Brian, I don’t know that much about the structure of WP code, but I’d love some insight into this if anyone can help.

    dgodot

    (@dgodot)

    15 years, 7 months ago

    Oh, another thing about this, get_site_option() is still working perfectly in the same context that get_option() is failing to return results.

    But, get_blog_option($blog_id, $key) returns false just like get_option, although the key value clearly exists in the database. Frustrating.

    astrader

    (@astrader)

    14 years, 10 months ago

    I noticed the same thing. I’m using WPMU and developing a report that contains data from multiple blogs. I was storing it in options on each blog with get_option and update_option, and that was working fine. But in the site-wide report, I am using switch_to_blog and trying to get options for the various blogs. For some blogs it works fine, but for most of them, what it gets is actually from the main blog (where blog_id = 1). I also tried get_blog_option, but it had the same result. I think I’m going to use get_site_option, etc., and just serialize an associative array with blog_id keys. But really, get_option should work properly when switching blogs. I looked at the code for a little while, and it looks OK to me.

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘Possible bug in get_option()’ is closed to new replies.