Some posts a while back indicate this may be variously a “mobile” plugin, or cache. Try a search for – ah, nev’ mind I see search can’t be bothered to work worth a shit as usual. Give me a few I’ll find something for you.
[Edit: okay, look through this one, there were some others, but can’t find them right now and search is NOT working, returns nothing even when I KNOW it should find the term *sigh*….]
http://wordpress.org/support/topic/100229?replies=32
Akismet v1.8.1 is the only plugin that’s enabled.
Well, I haven’t installed 2.1 so I haven’t a clue – does 2.1 have a cache table? Or is this not 2.1?
Could be a permission problem on the theme also. Check the permissions compared to the default theme.
Another option: try removing the themes (except the default) and then re-upload them.
They’re running v2.0.7. Should I tell them to upgrade?
And you’d think permissions are fine as it’s on the wanted theme right now.
Well…. try 2.0.8 first. I wouldn’t necessarily advise anyone to go to 2.1….
Pfft, I run it on both my sites and works great. 😛
Forgot about 2.0.8 though. I’ll upgrade that ASAP, but I don’t think any changes were made in the theme department between those two releases, but I could be wrong.
Regardless, an upgrade to 2.0.8 is a good thing. 😉
I see the same thing happening on our blog. It usually (not always, perhaps 40% of the time) happens after uploading a modified style.css file. WP (2.1) switches to another theme, in case there is no alternative theme it returns a blank page – no content whatsoever.
An indeed interesting behavior. I looks like it has to do with the cached content of a file not matching the new content on the file system…not sure if this is far fetched or makes sense at all – just a wild guess.
If it was only the servers filesystem, one would think WP returns the content except the file that can’t be accessed.
Weird.
Oliver
delicious:days
I found a reference in some other post about this issue, explaining that it indeed has to do with style.css (or index.php). If WP “thinks” something is wrong with either one, it switches to “default”.
Now if only one knew what WP’s “thoughts” are…even uploading one of these files on a heavily hit server should not really be an issue, or?
deliciousdays.com
Got to love those monologues. Anyway, this function seems to be the “culprit”:
validate_current_theme()
It checks for existence of both mentioned files, if for whatever reason PHP file_exists() returns a “false” the default theme is activated.
So this does come down to a file system issue…
deliciousdays.com
Good detective work, olivers!
Yeah, that’s what I figured. I knew most of that (if you delete the active theme, it’ll auto-revert to the default theme rather than freaking out), but I wasn’t sure if this was just a crap webserver (which wouldn’t surprise me) or something else. 🙂
Thanks.
Two questions, because I’ve been having this problem with my site since I switched themes.
One, where is that function located?
Two, I’m not running 2.1 right now, but 2.0.7, and I don’t have any major plugin that has been thought to be a problem (just widgets & akismet & event calendar for now). I’ve never had the problem before this theme. Obviously it’s something about my modified code, but what?
Has there been any news on this one? I’m having the same problem in 2.1.2
I found a work-around for this very annoying problem. I simply took the description comment from default/style.css and pasted it into my own theme’s css. Then completey removed the default directory from the server, and renamed my own theme’s directory to “default”. Kind of a dirty trick, but it works. WordPress is happy to use what it thinks is the default theme, and I’m happy to fool it.
But honestly, this isn’t a good way doing it… It’s quite a bad bug to work on!
