Mixed themes when using ajax

The Problem is that the ajax call is an independent call that runs through the rule chain and doesn't trigger the same rule.

Maybe we have to store the current theme in the session for ajax calls. Try to enable 'Retain the theme until a new theme is set' in settings to see if we can go into this direction.

I got webform ajax to work with the correct theme by using system:referer = page url. This changes things so that once someone clicks a link on the page, the next page will have the theme chosen with this rule. In my case the logo lead to front page, so I had to force default theme with drupal:is_front_page = true.

any other potential solutions to this? The page where my webform ajax is has lots of links and I'm not sure system:referer will work for me there. All the other pages on my site are using the 'default' theme, and I use seven as an admin theme.

We actually ran into a similar issue but fixed it on the ajax side. I'm wondering if this is similar.

With our ajax item in hook_menu we added..

$items['some/ajax/url'] = array(
... blah ...
'theme callback' => 'ajax_base_page_theme',
);

That allowed the ajax calls to not screw up the theme.

@caschbre thanks for pointing that out!

So it seems that most of the trouble is caused by erroneously implemented modules. The documentation tells that modules providing ajax callbacks have to provide this 'theme callback' in hook_menu!

But from my experience with contrib modules it's impossible to fix them all ;-)

I will try to implement a generic fallback within ThemeKey.

Committed http://drupalcode.org/project/themekey.git/commit/009e52113b76b2b21ae6e9...

Having the same or at least a very similar issue.

I'm currently transfering a site to a new theme and I'm using themekey to do it step by step. This site uses the Commerce module and I've added the paths and node types I need for the new theme, but when you change variants in Commerce it does a series of ajax commands to get information for the new variant. When I'm logged in it returns this information in the correct theme, but when I'm not logged in I get the wrong (default) theme and things go to shit because it can't find function declarations, loads the wrong css etc.

There is no hook_menu entry I can fix, it's all done through ajax commands.

If I inspect the ajax response I get when I'm logged in it looks like this:

command : settings
settings    {6}
  basePath  : /
  pathPrefix  : 
  ajaxPageState   {3}
    theme : correct_theme
    theme_token : 1TJ_jklHADxv95hfYdjxloCtu2HTKoHBMAcZyxCLPuc
    css   {1}
      sites/all/modules/contrib/commerce/modules/product/theme/commerce_product.theme.css : 1
merge : true

The one I get when I'm not logged in looks like this:

command : settings
  settings    {6}
  basePath  : / 
  pathPrefix  :   
  ajaxPageState   {3}
    theme : wrong_theme
    theme_token : DMtM-YvmBca_QH-kltK5894nD8kV8Ee-FSgmIkaKPX4
    css   {9}
      modules/system/system.base.css  : 1
      modules/system/system.menus.css : 1
      modules/system/system.messages.css  : 1
      modules/system/system.theme.css : 1
      sites/all/modules/contrib/commerce/modules/product/theme/commerce_product.theme.css : 1
      sites/all/themes/wrong_theme/css/html-reset.css  : 1
      sites/all/themes/wrong_theme/css/global.css  : 1
      sites/all/themes/wrong_theme/css/jquery.ui.theme.css : 1
      sites/all/themes/wrong_theme/css/print.css : 1
merge : true

So obviously the last one is all wrong, but why? Why does being logged in fix it? And how can I fix the problem? :)

The request url for the ajax request is /system/ajax which I have not added to themekey because that would break a lot of functionality. But at the very least I would expect it not to work regardless of being logged in or not.

Try the latest dev version of ThemeKey 3.x as mentioned in #6 and tell me if the problem remains.

Bah, I thought I just did, but I'm on 2.x. I tried to upgrade to 3.x now, but it failed, apparently because this Drupal version is too old and the function field_info_field_map() was added in Drupal 7.22.

I'll just see if I can see what you've done and see if I can backport it for now.

Nope, it did not work.

If I however hardcode in the correct theme in the themekey_custom_theme() function it works so at least I have something to go on for now. :) For some reason it behaves differently whether I'm logged in or not so that's where I'll start looking at least.

Found the problem. The correct theme is sent to ajax_base_page_theme(), but the token is not found to be valid for anonymous users. This probably has nothing to do with the themekey module.

EDIT: In fact I'll just hack it for now and set the skip_anonymous parameter in drupal_valid_token() to TRUE. Using themekey is just a temporary situation while we're implementing the new theme anyway. :)

Sounds like a page cache issue. Anonymous users share a cached token.
You should file an issue for commerce and link it here.

I used a combination of the proposed solutions here the system:referer and I did a few things under the AJAX section that might have solved this, no idea what did it but it seems to working now. Thanks a lot!

@TwiiK, here is an issue:
https://drupal.org/node/2177975

Any other guidance on this issue? I have tried the various fixes and nothing seems to work. I am also using commerce, and only see the issue in the following combination:

On a custom theme provided by a themekey switching rule
on a commerce product display page (a product detail page)
as an anonymous user
as a user who doesn't have anything in their cart (i.e., no anonymous session key yet)
using commerce_ajax_cart
only on themes based on drupal bootstrap theme.
when user clicks the add to cart button, I get the ajax error.

In the logs I get this:

PHP Fatal error: Call to undefined function _bootstrap_process_element()

Which is a function in the bootstrap theme (and subthemes)

I am using themekey 3.0, and have tried the various ajax settings provided but I still get the error. If I set 'retain theme until new theme set' it does work for auth'ed and anon users, but then other areas of my sites break. For example ,if the user browses back to the home page, the default theme does not display.

Of course, I could try another rule resetting the theme to default for the front page, but I just feel like there are probably other areas that I might miss. It's not entirely clear to me, on my own site, which pages would bring up the default theme right now, so I can't be sure I could catch them all in a rule.

Any hints?

Did you try the "Bypass" option and set your themes as safe themes at /admin/config/user-interface/themekey/settings/ajax

BTW Please open a new issue if the problem remains instead of posting in a closed issue.