Switchtheme does not work more than once

I'm having the same issue.
Just switched to the 6.x-dev version to allow for the browscap integration, and that works, and IS presenting garland to the crappy browsers that can't handle my new theme, BUT it is not allowing me to switch themes using the form anymore.

It was listed on the main project page that the 6.x-1.1 release integrated the browscap, but there is still no official release to match that version number. Is this project still being maintaned?? This is a HUGE module for my future purposes, even if simply for presenting a simple theme to poor browsers like IE. I'd be happy to take over maintaining it, and work out the issues if no one is still working on it.

Oddly enough, after a bit more testing... it appears that it IS still working fine for anonymous and "normal" authenticated users. But logged in as admin it is breaking, and not switching themes.

I've flushed all caches several times, I will investigate further, and review the code behind the module to see if I can find the issue.
If you are having this issue, test it out with multiple accounts, and as anonymous to see if it is having the same effect.

I will post more when I have discovered the issue.

I was encountering this too - it went away once I had gone to my user account page and saved it with a non-default theme selected. Still occurring for anonymous users though.

At a guess I'd say it's not interacting properly with whatever functionality gets the theme if the user has never picked on (ie it has trouble working out the 'default' setting)...?

it works fine when I am in the admin and in the local setup, but doesn't work on the 3rd time of switching as anonymous on production sites. Is it because many are using it on production sites?

I upgraded from 6.x-1.0 to 6.x-1.1 and encountered similar problems. Using the form block the theme would appear to not switch. It looks like the change is that in 1.0 it relied on a session variable to set a user's theme while in 1.1 it lets drupal core's theme handling do the work of changing the theme. It still uses the session variable for anonymous users and it appears that the session variable is still set from using the 1.0 version and 1.1 is still using it to display the theme, but 1.1 no longer changes the session variable, so it appears to not change even though you can see the theme selection change in the default drupal theme changing widget on the user account page.

The solution was to remove all the cookies for the site and log back in again. It all works as expected now.

Cleaning both Drupal and browser cache didn't work on my situation: I've tried both 6.x-1.0 and 6.x-1.1 (on another website I've 6.x-1.0 which works correctly, the server is the same with the same configuration)

Clearing either cache shouldn't be any help. You need to specifically delete the cookies for the site in question from your browser. Ask google or refer to the documentation for your browser if you need help deleting cookies.

Even deleting cookies from the browser still doesn't work: anonymous users are able to see the combo box, but clicking "switch" reloads the website with the same default theme. Very very very strange

I've found the bug on my website: the user "0" didn't have "0" on the uid field, but "3"... I don't know why.

I'm sorry.

Please test attached patch.

I installed the patch but it didn't solve my problem.

On some pages the toggle works, however on some not.

http://www.visualimpression

Theme switch buttons are the sqares in black and white in the lower right.

Themes switching works for:

/aktuelles -> /node
/kontakt -> /contact

does not work for other nodes like:

http://www.visualimpression.de/visualisierung/aussen (some node with cck)

Could anyone help?
Could anyone give a hint how to help?

I'm very sorry but I only understand little about the internals of drupal codin so I can't provide a patch but I was examining the behavior and I can tell, there are 2 major bugs.

1. If it's a signed in user and if he is allowed to switch theme, the theme doesn't switch instantly but on the second page reload.
2. If it's not a known user or he's not allowed, than the module works fine on non-node pages but doesn't work on node pages for me.

Its not not working for me ether 1.0 or 1.1

It's just an observation, non-switching usually happens on the live site
and when the browser waits for the new theme, if it waits for too long,

It loads the old theme from the cache of the browser,
probably, switchtheme should require to get new theme from the server
and not from the client's browser save files.

[Edited by KiamLaLuno in order to show the last sentence in normal style rather than bold style]

Good thinking. Unfortunately themes do not work that way.

The "theme" is never sent from the server to the browser at any point - it's used by the server while assembling the page. As far as the browser is concerned, the page is completely normal HTML. Even the CSS files will appear to be at completely different locations, so there's no danger of styles cacheing between themes.

It might be that the *page* is cacheing at the browser level, but Drupal already sends all sorts of no-cache instructions with every page request.

If the browser loads the old one, how do we control it from drupal configuration, instead of clearing the browser cache every change of theme?

I also observe this when you logout and go to other pages, it will load the old page where you have previously logged in like it will show the admin menu.

hope this module works soon, it's very useful

Hi, I came across this behavior too. Unfortunately my server is undergoing some changes so I can't just jump in the code right now but I have found some additional behavior that might help track it down.

If I go into Themes and Restore Defaults and then re-enable all the themes, I can switch themes once again, only once though.

If disable the theme that Drupal is stuck on, then clear all the cache, and then go to a non-admin page, it still uses the disables theme! (that's got to be a clue to someone).

I tracked down a similar problem in a different theme module which might help give you some ideas, this issue is here: http://drupal.org/node/421644

I also checked on node_load which does its own caching separate of the Disable Cache feature as far as I know (http://drupal.org/node/221081) by disabling its cache, that didn't help but I thought I would mention it in case it give someone else an idea.

I have applied the patch above but it made no change in behavior. Also, I am a developer so I can say straight up this is not a browser cache issue. All my browsers have cache disabled and I primarily use FireFox with plugins that give me finer cache control and guarantee it's not caching anything since I need it this way for my own development.

If this isn't resolved when I get my computers back in order I'll jump in the code and try to track it down but that might not be for a while so hopefully someone else will be able to figure it out in the meantime.

I just noticed that this is rather sporadic. I logged out, logged back in, all of a sudden I could change themes at will. Just like I was for hours before it suddenly stopped. However, I logged out and still the theme was stuck. I moved to a different page and then back, now I could change themes while not logged in. I really haven't found a consistent pattern to it yet but will keep a careful lookout and post more if I see anything new.

If you click on "Try out a demostration" on Switchtheme project page, you can see a site in which the theme changes only the first time you click on Switchtheme block!!!

I think priority have to be set to "critical". Don't you?

Agreed, it makes it essentially unusable.

I put a write to log file (my own debug routines) at the start and exit point of every function in switchtheme.module. It's seems from the trace that the problem is in the very first function called is switchtheme_init.

I don't know the fix, just that this is what is happening (I will follow up soon after some analysis - right now I'm just making some diag. info. available for anyone who wants to help fix this). Below is my trace output and attached is switchtheme.module (had to change extension to txt so it would upload) with my trace code so you can see what is producing the trace.

I have also added the code to theme_init (will attach file as well if allowed to attach more than one file - I've never attached a file on this website before) since that is the critical system call that we must watch. This should be plenty for the owner to fix it since he knows the code intimately and can now see exactly how it is failing.

"acrylic" is the theme it is stuck on and "smoothBlue" is the theme I was attempting to switch to.

Found it! Everyone please check and see if this also works for you.

The attached patch was created by my IDE so it may not work for you. However, It's only two lines so it's a dead easy manual change.

In case it doesn't work, in switchtheme_init just change:

switchtheme_init should now reflect the logic in switchtheme_switch_form_submit. I should mention that this fix is without the previous patch in this issue applied. I had it applied at one point but it made no difference to whether the module worked so I removed it.

An alternative solution, perhaps a little cleaner. Either way hopefully the maintainer will look at these and make his own fix from them as I am not sure if I have taken all the logic into account. Please note that if you want to use this patch apply it after applying the patch in #24.

Something to remember, Drupal loads from index.php twice on each page change and I have been seeing it load 3 times while working on this bug, perhaps because of the theme change or perhaps some other module I have installed. In any case, with this module I have seen it make a difference in how I had to code it to work right.

Oops, wrong patch, here is the new one that was meant to be in the above.

After some testing I found the patch didn't work for non-logged in users. Digging deeper into this module's workings to figure out exactly what's going on with it I've created the following patch - it should work as I went through it quite thoroughly. I've also attached the final file (you will need to remove the .txt extension added so it could be uploaded) that can be copied over the old file in case the patch doesn't work for some people (remember to preserve your original file if you do this).

Testing and feedback appreciated.

Another thing that just came up. When I switched to a non-home page as an anonymous user it stopped working. On investigating it came down to another module, in this case nodewords getting there first.

The solution is to change the module weight of switchtheme. In my case -1 was sufficient. It would be useful if the developer would add this into the install script since 'being first' is an important attribute of this module. Or even better, make it an option in the admin section.

If you don't know how to change the module weight in the DB just install the module 'module weight' and then you can change through the interface under 'modules'.

I took your patched .module and changed module priority.

This worked fine for most cases.

However for anonymous user after you switched the theme, it will be switched for some nodes, but not for all. I'm not quite sure how to find out which nodes are affected, but there are certain nodes still appearing in the old theme. You can switch for those also by reselecting the new theme. This can also appear between two different nodes of same type.

Thanks for the feedback!

Without looking at your system I couldn't tell you what your problem might be however at a guess, it sounds like either you have some pretty aggressive caching or you have another module that's interfering intermittently.

If you can figure out a way to duplicate the issue predictably you might try turning off your cache and then execute the mysql statement "truncate cache;" (and truncate any other cache tables you may have) on your DB (careful to only do this on caching tables as it removes all data from your table) just before switching in a case where it normally wouldn't work and seeing if that fixes it. If so then you know you are dealing with a cache problem.

The only other thing I can suggest is the age old method of switching off modules one at a time (starting with the most likely to cause a conflict) until (hopefully) the problem stops and then you'll know which module is in conflict.

If it happens to be that there are still problems within this module's code, sorry but I couldn't help you, not without being on your server tracing things through like I did on mine to track down the issues I had.

One last thing - if you have some programming ability you could try temporarily putting a debug_backtrace() in init_theme (or is it theme_init?) as you might catch some other module calling it before switchtheme does. If you see that it doesn't get called at all when you catch it not working then that's a strong indicator of a caching issue.

If/when you do find the problem please post the solution.

Hello and thanks for the great help.

The problem seems to be a caching problem. Disabling performance options and truncating all database tables named cache and cache_* seem to solve my problem.

Can I now reactivate performance options safely?

However it seems useful to me, to integrate some function solving the cache problems.

I don't have to many modules installed. Only a little CCK, some panels, views, WYSIWYG, IMCE and some casual stuff. Any special suggestion? I could give you access data for personal review to the site if you like to. I still didn't learn how to code or debug Drupal properly.

Best Regards

Try turning your performance on and see how it goes. There are levels of caching so try the least aggressive and work your way up to where you want to be and see if/where it breaks. Also, if you have memcache or some other additional caching you can try disabling it, then working just with the Drupal core caching, get that working first and then add in the additional caching modules and see if they break it.

In other words, at this point it's all a matter of just playing with parameters and seeing what you can get away with.

If you are lucky then just clearing your cache will have fixed it and you can turn everything on and it will all work now. I personally tend to take the slow and methodical approach (which I just gave you) so when something breaks I have a good chance of knowing exactly the the variable that broke it.

Hi antrophos,

Just wondering if you got it all resolved?

All the best,
Reg.