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.

    switchtheme_init/S
      switchtheme_init/1
      switchtheme_init/2
      switchtheme_init
      switchtheme_switch_form_submit/SE
      switchtheme_init/3  custom_theme: {NULL}
      switchtheme_init  _SESSION[custom_theme]: acrylic
      switchtheme_init/4  custom_theme: acrylic
    switchtheme_init/E
    init_theme/S
      init_theme/1  theme: {NULL}
      init_theme/2  theme: smoothBlue
      init_theme  $custom_theme: acrylic
      init_theme/3  theme: acrylic
      init_theme/8  theme: acrylic
      init_theme/9  theme: acrylic
    init_theme/E2
    switchtheme_block/S
      switchtheme_block/3
      switchtheme_block/4
      switchtheme_switch_form/S
        switchtheme_select/S
          switchtheme_options/SE
        switchtheme_select/E
      switchtheme_switch_form/E
      switchtheme_switch_form_submit/SE

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:

  if (isset($_SESSION['custom_theme']) && (!isset($custom_theme) || $custom_theme === '0')) {

to:

  if (user_access('select different theme')) {
    # Do nothing, this reflects the logic in switchtheme_switch_form_submit called just above 
  } elseif (isset($_SESSION['custom_theme']) && (!isset($custom_theme) || $custom_theme === '0')) {

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.

Hello,

sorry but I wasn't able to check this yet because of other projects. Probably I won't give an answer soon.

For me, disabling all the caching options in the "Performance" page seems to solve the problem...But this is not ideal.

Many thanks for the patch in #27 - it is a notable improvement.

Still, after clearing the cache, for anonymous users on my site to actually switch the theme requires
* switch using the selection box
* that brings you to a new window with a theme you (most likely) didn't choose
* then go back one in window history and reload that window
Switching theme doesn't seem to be a problem for registered users.
Hopefully a better pacth will be forthcoming.

Regards.

-rg-

Hey Tilt_11 & ungeek. I appreciate your feedback but if you are having problems on your system you need to do some troubleshooting of your own so whatever additional variables that your system is failing with are taken into account.

Also, did you try the additional step in #28 ? You may have to play with the module weight somewhat (try a large negative #) or try the old tried a true method of disabling other modules that might be in conflict (theming and advanced caching modules are likely candidates.)

This thread was posted January 28, 2009, and August 11, 2009 Maintainer (sun) came with a patch that not fixes this problem. I have now installed it on a new support site for drupal users ( http://drupal.no/ ), and will that this seemed no one should have to test out several patches. I have followed this solution -> "# 24! - It does not work for the visitors, so therefore I ask whether if it is possible that this module will be ready for use soon?

Ole Martin, I posted patch in #24. If you look you will see the most updated patch is from #27 and being the latest that is the one you should be using. As far as I know the patch from # 27 works although you may need to follow the instructions in #28 depending on what additional modules you have.

As for when it will be ready and whether people should be testing patches. I can't say when it will be ready since I am not the maintainer, don't know the maintainer, and don't know if the maintainer is even maintaining any more since I've seen no input from him/her for a long time.

As for you or other people testing patches -- this attitude really disincentivizes me from contributing. This is not my module so if people like you couldn't be bothered helping test fixes (the least you could do for something that is free) why should I bother to contribute my expertise (over 20 years worth in software) and fix bugs? After all, it's not my module, I have no more responsibility to it than you.

@ Reg
my post was meant for the sun - and KarenS, the maintainers . I've seen that you and many others have helped many here, and that is great. So what I meant is that the Maintainer for Switch Theme should update the module so that many more could enjoy it.

Sorry that my post was written so that it could be misunderstood. When I get more time I will teach me to patch, but it will wait until after Christmas

Thanks, Ole, very helpful contribution.

+++ ./switchtheme.module	2009-10-18 22:45:08.000000000 -0700
@@ -67,13 +67,9 @@
-  // If query parameter 'theme' is set, we always assign a new theme.
-  if (isset($_REQUEST['theme'])) {
-    $form = array('values' => array('theme' => $_REQUEST['theme']));
-    switchtheme_switch_form_submit('', $form);

@@ -81,8 +77,15 @@
+  if (isset($_REQUEST['theme'])) {
+    $form = array('values' => array('theme' => $_REQUEST['theme']));
+    switchtheme_switch_form_submit('', $form);

I don't really understand why you moved this code, please revert.

+++ ./switchtheme.module	2009-10-18 22:45:08.000000000 -0700
@@ -81,8 +77,15 @@
+  } else {

Not following Drupal's coding standards - we write if and else on separate lines. See http://drupal.org/coding-standards for more info.

+++ ./switchtheme.module	2009-10-18 22:45:08.000000000 -0700
@@ -81,8 +77,15 @@
+      $new = $_SESSION['custom_theme'];

@@ -91,10 +94,22 @@
+        $new = $browser_theme;

If we really need this $new variable, then it needs at least to be named $new_theme.

+++ ./switchtheme.module	2009-10-18 22:45:08.000000000 -0700
@@ -91,10 +94,22 @@
+  if ($new && empty($custom_theme)) {
+    $_SESSION['custom_theme'] = $new;
+    $custom_theme = $new;

In case we implement new logic here (hard to determine with the moved code), then we also need to update the inline comments to explain the new behavior.

+++ ./switchtheme.module	2009-10-18 22:45:08.000000000 -0700
@@ -91,10 +94,22 @@
+    # We shouldn't need cache_clear_all() but we include it in case some more aggressive
+    # caching module that may get added makes it necessary. It is however required in 
+    # switchtheme_switch_form_submit() so if tempted to remove it, leave in it in the 
+    # other function.
+    if (empty($user->uid)) { 
+      cache_clear_all($base_root . request_uri(), 'cache_page');
+    }

This code needs to go, because that is an entirely different issue in the queue.

+++ ./switchtheme.module	2009-10-18 22:45:08.000000000 -0700
@@ -145,7 +160,7 @@
-
+    

(and elsewhere) Trailing white-space introduced here.

This review is powered by Dreditor.

Ole Martin, fair enough. I tend to agree about the maintainer and sorry that I jumped (I spent a lot more time on this module than I expected to).

Hello Sun,

That was actually my patch, but no worries. Are you able to tweak that patch to satisfy Dreditor? I'm in the middle of launching a new business so I am not going to have time to work on this for months I would imagine.

Also if you could add an admin. field for the module weight as mentioned in #28, that would round off all the issues I discovered.

And thanks for jumping in! I think a few of us were wondering what was happening.

I can't troubleshoot on my live site right now, so I recreated a test site: Same files, same Database on the same server with the same PHP settings and guess what...the module works perfectly on the test site! I'll try to research a little further when I have time...which won't be this week...In the mean time, I have no idea what makes a difference between my live site and my test site...

...Sorry, I know this doesn't help too much...

Thanks Tilt_11. At least you know it can work on your site, that's half the battle won, congratulations!

Hi Reg !

I just happened to see your reply, and installed the Util module for Drupal 6.14. Setting switchtheme's weight to -1 doesn't seem to solve the problem : the selected theme only runs when dropping back to (and reloading) the previous browser window. I checked with two different browsers (arora and epiphany).

The switchtheme module's weight was the lowest of all, at -1. What additional information would you like me to provide ?

Cheers.
-rg-

If the first time, I'm on a page like ..../drupal/fr and I click on the switch button, the theme switch correctly but the drupal path is changed to .../drupal/fr/node !!! When I'm on this page, it doesn't work again. (Behalve with cache disabled as annouced above)
If a change back the path to ..../drupal/fr, I can switch to another theme.

This might solve your problems - I came across it just now - make sure the 2 lines of code with "cache_clear_all" are changed to look like this:

      cache_clear_all();	# Must clear all page and block cache because pages that we are not viewing may be cached with a different theme

In the patch those lines pass two parameters to "cache_clear_all" to make sure we only cleared the current page. However when doing that it looks like it is reverting back to a previous theme when you change to another page that's already been cached so you have to clear all the pages from the cache when switching. The way you do this is by passing no parameters - which as you can see is how the line is now.

I can't supply another patch but Sun should easily be able to take what I have provided and incorporate it into his module (probably less than an hour after tweaking for the Drupal editor) - sorry guys, I'm getting very busy and have to focus elsewhere.

If you still have problems I can only suggest what I suggested before, try disabling caching and/or other theme related modules to see if you are suffering a conflict. If this small fix does help, please let me know.

Thanks Reg,

Your #48 brought me nearer to the reason I have problems with switchtheme.
I wouldn't consider using a general cache_clear_all() on an active system, because of the potential performance impact.

Since I had done all my tests on the front page of my site, I tried to switch theme in an "inner" page - and the problem disappeared (still using the latest patch provided on this thread).

So, I'll rather look at my odd way to bring up the front page (on a multi-lingual site with a main user language different from the administration language) and try to fix that or dismiss the issue entirely. Still, somewhere along the migrations from 6.9 to 6.14, things have changed that made the problem pop up...

Thanks & regards.

-rg-

(edit)

Actually, the problem is now solved. It arose because my front page sends back a Location header with the URL of the site's french front page as target. This URL was not completely specified, which caused the problem when switching themes - the cache_clear_all(..., ...) wouldn't drop the intended page.

Truly glad I didn't want to use a general cache_clear_all() ...

Very cool, glad you solved it.

Have similar issues, subscribing.

All as I can suggest is make sure you have the latest patch from this issue because there are bugs that it corrects.

I'm getting the feeling the maintainer isn't going to incorporate it unless someone makes it pass Dreditor for him and I don't have time (it was my patch) so I think we are stuck with this module remaining incomplete without using patches.

In response to sun in #41:

Here is the patch from #27 with your amendments and a couple of other minor fixes, namely the use of lower case constants and and use of an undefined global variable.
It applies to the current dev version.

Except -

+++ ./switchtheme.module 2009-10-18 22:45:08.000000000 -0700
@@ -91,10 +94,22 @@
+    # We shouldn't need cache_clear_all() but we include it in case some more aggressive
+    # caching module that may get added makes it necessary. It is however required in
+    # switchtheme_switch_form_submit() so if tempted to remove it, leave in it in the
+    # other function.
+    if (empty($user->uid)) {
+      cache_clear_all($base_root . request_uri(), 'cache_page');
+    }

This code needs to go, because that is an entirely different issue in the queue.

* I'm guessing you are referring to #361832: Allow to switch themes with page caching enabled, which currently has no patch to fix the issue.
* Without that caching part this patch doesn't actually do anything.

Maybe this patch could be used as a starting point to #361832: Allow to switch themes with page caching enabled because the original post in this issue says

Caching is disabled and still no effect for both logged in and anonymous users.

and this patch only seems to fix caching for anonymous users.
So I think this issue has gone off track somewhat and a lot of the people in here actually should be in that other issue.

Also, I'm not sure if it's just my site but with this patch anonymous users have no problem but authenticated users can't change themes.

As @Agileware already figured, this entire issue went off track.

Marking as duplicate of

#361832: Allow to switch themes with page caching enabled
#981662: Not switching for authenticated users