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.

Now on a new server

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

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

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.