Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Using theme1 and this rule:
drupal:path = node/add/contenttype > theme2
When you have multivalue field on /node/add/contenttype and use "Add another item" button, the updated form is returned with wrong theme (theme1). Same applies for drupal:is_front_page + node/add/contenttype set as frontpage, and probably others...
Comments
Comment #1
mkalkbrennerThe 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.
Comment #2
KimmoT CreditAttribution: KimmoT commentedI 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.
Comment #3
meecect CreditAttribution: meecect commentedany 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.
Comment #4
caschbre CreditAttribution: caschbre commentedWe 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.
Comment #5
mkalkbrenner@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.
Comment #6
mkalkbrennerCommitted http://drupalcode.org/project/themekey.git/commit/009e52113b76b2b21ae6e9...
Comment #7
TwiiK CreditAttribution: TwiiK commentedHaving 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:
The one I get when I'm not logged in looks like this:
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.
Comment #8
mkalkbrennerTry the latest dev version of ThemeKey 3.x as mentioned in #6 and tell me if the problem remains.
Comment #9
TwiiK CreditAttribution: TwiiK commentedBah, 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.
Comment #10
TwiiK CreditAttribution: TwiiK commentedNope, 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.
Comment #11
TwiiK CreditAttribution: TwiiK commentedFound 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. :)
Comment #12
mkalkbrennerSounds like a page cache issue. Anonymous users share a cached token.
You should file an issue for commerce and link it here.
Comment #14
Selfirian CreditAttribution: Selfirian commentedI 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!
Comment #15
Ares_ekb CreditAttribution: Ares_ekb commented@TwiiK, here is an issue:
https://drupal.org/node/2177975
Comment #16
meecect CreditAttribution: meecect commentedAny 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?
Comment #17
mkalkbrennerDid 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.