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)
Wow. I’ve never had that problem before. That’s new.
Thanx for the info….
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.
Wow, that’s a weird one. Good detective work and thanks for sharing.
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.
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.
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
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”
Alex:
Have you opened a ticket in Trac? I’m sure others would benefit from this info…
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 🙂
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.
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
Hi Alex!
Thanx for the great info.
greetings
martin
[…] masalah yang sama. Satu-satunya alternatif solusi yang saya dapatkan di internet hanyalah yang diberikan oleh Alex King. Itu pun gagal menyelesaikan […]
[…] plugin for wordpress. BarCampRDU needs and reminders had some splendid points. Take a look at Weird WordPress Settings Issue. It was worthy to spend some time looking over wsWired Theme for WordPress by Wired […]