Selection rule "current theme" has no effect / breaks

same problem here

Subscribe, same problem here, same scenario.

Hmm. Perhaps the theme selection is happening after the variant selection process, so that at the time the tests are being run, no theme has actually been selected? What is selecting the theme?

No, testing this i see you're right; the access rule has absolutely no effect due to an error in the test. I checked in a fix. This is a CTools change, so moving to proper project.

+1 subscribing

Not sure if this is a safe solution but:
1.Go to sites/all/modules/ctools/plugins/access/theme.inc
2.Look for this function ctools_theme_ctools_access_check() (near line 43 in 6.x-1.6)
3.It should look like this after correction:
function ctools_theme_ctools_access_check($conf, $context) {
// As far as I know there should always be a context at this point, but this
// is safe.
/*if (empty($context) || empty($context->data)) {
return FALSE;
}*/
return $conf['theme'] == variable_get('theme_default', 'yourtheme');
}
I've commented the if statement for $context. I don't know if this is safe but without that line and with correction from $GLOBALS['theme'] to variable_get('theme_default', 'yourtheme') everything works for me.
Hope this will help someone.
If you have better idea please share, please tell more about that $context variable, why it shouldn't be empty?
Thanks

If you'd look in the most recent CTools -dev you'd see that's basically the change that's checked in. Not sure why you're investigating something that's already fixed.

I have 2 variants of a page as frontpage. Both have an access check against the used theme (the main theme and my personal theme). This doesn't work. At the access check 'custom_theme' an 'theme' are empty, only 'theme_default' is filled. If i use an access check against the theme with a panel on this page, it works correctly. If I now load the page, theme-variable is empty at the first access check (page variant) and correctly filled at the second check (panel).
Is it possible that a change in module weights could fix that problem?

For me it works if i call if (empty($GLOBALS['theme'])) init_theme(); at beginning of ctools_theme_ctools_access_check($conf, $context) but i don't know possible problems with this hack.

#9: Ahh you have user themes enabled? I suppose that needs to be checked as well. It's hard for me to decipher where in the system you think the theme is currently set at the time the check is run, so I am not quite sure.

Changing module weights probably does not do anything.

  else {
    $theme = variable_get('theme_default', 'garland');
  }

That code should see the default theme and compare it.

Module weights doesn't help. I agrree.
All works as supposed if the check is called for a pane on a page. Its perfect, no need to change!
In your function the gloabal $theme variable is checked. And this is the right solution to get all changes to the default theme. If a user selects a special theme or a modules does - all works correct with this check against the global $theme.

The problem is, that the global $theme is set by drupals init_theme() and this is (in my case?) after the access check to select a page variant.

I work for some days now with expicitly calling init_theme and see no negative behavior. If I look in drupals theme.inc I can see that it will never run twice because itself checks against gloabal $theme.

We also can delete checks against default_theme or custom_theme because its also done in init_theme,

So the access check schould simply look like this:

function ctools_theme_ctools_access_check($conf, $context) {
  // because in - some cases - the access check runs before the theme is loaded, we have to check if the theme system is correctly initialised
  if (empty($GLOBALS['theme'])) init_theme();
  // check if the current theme is the same as the access rule needs
  return $conf['theme'] == $GLOBALS['theme'];
}

Any other opinion?

Regards, Martin

We absolutely positively should not init_theme() here. That's why our check defaults to the variable that contains the theme.

I did, however, add a check for $user->theme in case that's going to override the default theme. Perhaps that's what we're missing in your case.

/**
 * Check for access.
 */
function ctools_theme_ctools_access_check($conf, $context) {
  if (!empty($GLOBALS['theme'])) {
    $theme = $GLOBALS['theme'];
  }
  else if (!empty($GLOBALS['custom_theme'])) {
    $theme = $GLOBALS['custom_theme'];
  }
  else if (!empty($GLOBALS['user']->theme)) {
    $theme = $GLOBALS['user']->theme;
  }
  else {
    $theme = variable_get('theme_default', 'garland');
  }

  return $conf['theme'] == $theme;
}