Skinr css-classes for views-blocks rendered wrong for user 1

I'm having the same problem with the Acquia Prosper theme. When I view it as an anonymous user, the blocks are displayed with the correct CSS classes. However, when I login as admin, the blocks are displayed with the default CSS. I have all Drupal caching disabled and yes, I've tried clearing the cache in the Performance screen, clearing my browser cache, etc..

Interestingly, when I view my system logs, I notice Page Not Found errors for User 1 for the following file:

sites/all/themes/acquia_prosper/style.css

This file definitely does not exist in the acquia_prosper directory, but it seems that it only tries to access the style sheet when User 1 is logged in. Therefore, I'm wondering if this has something to do with the issue...

bkonia, did you delete all the files in the acquia_prosper directory before updating? I don't think these two things are related.

But back to the original issue, we have had this randomly come up a few times too. Originally it seemed isolated to cases where someone had switchtheme and/or any other theme-changing-per-X module enabled at any point, but I think it's cropped up a couple of times where that is not the case.

Either way, Fusion is just using Skinr in its standard form so I'm not sure how something like this could be occurring in Fusion itself :\ I wish we could reliably replicate the different skins per user bug...

Here are other examples of similar issues:
#829002: Block headline style disappear when logged in
#716172: $skinr not outputting classes for logged in users

We've had one or two reported on our own site's issue tracker too.. usually doing a cache/aggregation/re-enabling theme/etc dance fixes it but it's very mysterious.

I figured out the problem. It actually had nothing to do with the fact that it was User 1. The problem was that my admin account had previously been set to a different default theme. I subsequently disabled that theme when I switched to Acquia Prosper. Thus, the site's default theme was Aquia Prosper and the admin's default theme was set to a disabled theme. I corrected the problem by re-enabling the original theme and changing admin's default theme to Acquia Propser.

I would suggest adding some type of checking in the Skinr module to notify a user when his default theme is currently disabled. Alternatively, you could have Skinr simply ignore the user's default theme if it's disabled and use the site default, or automatically switch the user's default theme to the site default.

Oof, that helps a lot to know -- it seems like there are a lot of permutations of this issue that cause slightly different variations.

Thanks a lot #5, this solved a long time issue!