Weird WordPress Settings Issue

Posted in: Crowd Favorite, WordPress, Development

I debugged a strange WordPress issue for a client today, one I hadn’t seen or heard of before, so I thought I’d document it.

The symptoms:

  • IE7 would try to download the wp-login.php page instead of loading it.
  • Mobile devices (using my mobile plugin would complain that they could not view the site due to the wrong content type (perhaps showing a 406 error).
  • The feeds were not validating.

And other problems that had already been fixed:

  • All plugins were deactivated.
  • The theme had reverted to the WordPress default theme.

All of these symptoms ended up being caused by a single problem (technically, multiple instances of the same problem). The WordPress options table (normally named wp_options) had recently had problems, and a variety of settings had been flagged in a ‘notoptions’ cache.

I hadn’t seen the ‘notoptions’ cache before, but it appears to be a list of options that were requested, but that did not exist in the options table (or were not returned as expected by a query). When the options table was having problems, this ‘notoptions’ list grew to include things it shouldn’t have. Specifically, it was including:

  • html_type - which tells the browser to serve the pages (in most cases) as text/html.
  • blog_charset - which tells the browser what character set the pages are in.
  • plugins - which plugins are active.
  • template/stylesheet - which theme to show.

With these things in the ‘notoptions’ list all sorts of stuff broke. WordPress wasn’t getting the information for these options, and it was information is needed to work properly. While I was tracing code to find out what was going on, I discovered the ‘notoptions’ references in the get_option() function (line 206 wp-includes/functions.php). Commenting out the code that returned if the requested option was in the ‘notoptions’ list seems to allow the rest of the code to flow properly and also reset the ‘notoptions’ list to exclude the settings that actually do exist.

The lines I commented out were 215-217:

$notoptions = wp_cache_get('notoptions', 'options');
if ( isset($notoptions[$setting]) )
return false;

After that ran once, everything worked properly again.

Hopefully this will be helpful to others that find themselves in similar situations.

(Posted with client permission)

Popularity: 21% [?]

Posted July 23rd, 2007 @ 2:35 PM

14 Replies

  1. Jenny adds this Comment:

    Wow. I’ve never had that problem before. That’s new.

    July 23rd, 2007 at 3:14 pm

  2. Ken Reidy adds this Comment:

    Thanx for the info….

    July 23rd, 2007 at 3:16 pm

  3. Sue adds this Comment:

    I’ve seen this happen, with Firefox. Not on Wordpress, but on a site using a database (mySQL I presume), but it’s not my site so I can’t be sure. Same thing, it tries to “save it to disk,” or gives me the option to select which program to open it with. Glad to know it was on their end, and not anything I could do about it. Other than contact them and let them know there’s a problem, that is. Thanks for posting this. It’s good information to have.

    July 23rd, 2007 at 3:44 pm

  4. Matt W adds this Comment:

    Wow, that’s a weird one. Good detective work and thanks for sharing.

    July 23rd, 2007 at 4:37 pm

  5. brVince adds this Comment:

    I’ve experience it with firefox too but seems it was just because of slow internet connection, reason it downloads the “wp-login.” thanks for the info.

    July 23rd, 2007 at 4:38 pm

  6. Alasdair Davies adds this Comment:

    I’ve had the theme reset in the night to the default WP setup to find a client puzzled as to why their red website is now blue!

    I too was puzzled so “just incase” I copied the modded theme over the default one incase it happened again in the small ours of the morning and stamped the theme thumbail “FALLBACK”

    A few days later there was a press release and a great number of people were visiting the blog. Just out of interest I checked the blog theme to see which version it was on. Yep.. Fallback. Glad to see the bug has been found now though.

    Great work.

    July 23rd, 2007 at 6:22 pm

  7. DD32 adds this Comment:

    One of the first things i do whenever i’m having any WP problems is to empty out the cache folder /wp-content/cache/
    (If the cache is enabled)

    That would’ve cleared the notoptions cache and let things continue on.

    Of course, If there was anything wrong with the tables still then you’d still have had issues.

    D

    July 23rd, 2007 at 8:51 pm

  8. AJ adds this Comment:

    Wow. That would have been a tricky issue to isolate.

    Btw, the link to your wordpress plugins is incorrect. It uses the subfolder “project” instead of “projects”

    July 23rd, 2007 at 9:17 pm

  9. Doug Stewart adds this Comment:

    Alex:
    Have you opened a ticket in Trac? I’m sure others would benefit from this info…

    July 24th, 2007 at 3:34 am

  10. Bob! adds this Comment:

    I’ve seen this a few times and it was caused by the server I was on having issues with the html service. Anytime it gave me the download/save options I’d check the CPanel and the html was down again. When the html service was restarted it all worked again.

    Now on a new server :)

    July 24th, 2007 at 11:24 am

  11. Mark Jaquith adds this Comment:

    Likely caused by this bug. Only WP 2.2 and 2.2.1 are affected. 2.2.2 and 2.3 will both have the fix.

    The way I could consistently trigger the bug was by adding an option and then updating it on the same load. ‘notoptions’ wasn’t getting properly updated in that situation.

    And just FYI, the reason for the notoptions cache is because sometimes plugin authors are lazy and don’t actually add all their options by default (that is, they assume non-existence = false). So before, there wasn’t a way to cache non-existence, and each request would make a SQL query (sometimes 100 times a page, with the most eggregious offenders).

    Another way the notoptions cache could become stale is if a plugin does a very very bad thing and updates an option in the database directly without using the API.

    July 24th, 2007 at 10:42 pm

  12. Thomas adds this Comment:

    Wow, I had this problem a while ago, thought my blog was hacked and installed it new. I think next time I can save my time and fix this with your tips, so thank you.
    This entry is now bookmarked in my “may be usefull someday”-folder…
    Thanx and greetings,
    Thomas

    August 5th, 2007 at 4:51 am

  13. Hundenahrung adds this Comment:

    Hi Alex!
    Thanx for the great info.
    greetings
    martin

    August 24th, 2007 at 9:04 am

  14. Wordpress 2.2.2 Sucks! | Cosa Aranda adds this Pingback:

    […] masalah yang sama. Satu-satunya alternatif solusi yang saya dapatkan di internet hanyalah yang diberikan oleh Alex King. Itu pun gagal menyelesaikan […]

    September 8th, 2007 at 9:36 pm

Add a Comment

Please note: Use of a non-personal web site or blog in the field below and/or comments that are off-topic, personal attacks, or support requests will likely be removed at my discretion.

Note: This post is over 9 months old. You may want to check later in this blog to see if there is new information relevant to your comment.

CAPTCHA or a Challenge Response E-mail? » « Around the web

About This Site

This is the personal web site of Alex King, an independent developer based in Denver, Colorado USA. More...


Crowd Favorite

Crowd Favorite is my software and web development business.

We build web applications, design and develop custom WordPress themes and plugins, and build custom sites using WordPress as a CMS.


I also have a tumblog that aggregates my online content from other services (Twitter, Flickr, del.icio.us. etc.).

Ads