Hi,
Admin theme module prevents other modules from assign a custom theme when the user does have admin permission.
The following code is causing this issue

  // we should not show the admin theme if the user has no access or the path is in the disallow list
  if (!user_access('access admin theme') || $admin_theme_disallow) {
    unset($GLOBALS['custom_theme']);
    return;
  }

I commented unset to get it to work. I don't know any better way for fixing it.

Thanks

CommentFileSizeAuthor
#2 admin_theme.module.patch782 bytessirviejo

Comments

davyvdb’s picture

davyvdb commented
Status: Active » Closed (duplicate)

#508536: play nice with $custom_theme

sirviejo’s picture

sirviejo commented
StatusFileSize
new admin_theme.module.patch782 bytes

I think the best solution for this is unsetting ONLY when value is the same value defined in admin_theme variable. With this we avoid unsetting values that has been previously setted by other modules with boot hook or init with less weight.

if ($GLOBALS['custom_theme'] == variable_get('admin_theme', '0')) {
unset($GLOBALS['custom_theme']);
return;
}

Attached my patch.

afox’s picture

afox commented
Status: Closed (duplicate) » Needs review

+1 for this fix.
Tested the patch and it works. This is a simple precaution that removes quite a lot of hassle. I don't think this is really a duplicate of that mentioned issue. The issue here is that admin_theme unsets the theme even if admin_theme has not set it itself.

sirviejo’s picture

sirviejo commented

how about my fix in #2 does any contrib be able to test it?

afox’s picture

afox commented

Fix #2 worked for me when I had problems with domain_theme.

sirviejo’s picture

sirviejo commented

in my case the problems happens with mobile_tools

geek-merlin’s picture

geek-merlin
Primary language German
Location Freiburg, Germany
commented
Priority: Normal » Major
Status: Needs review » Reviewed & tested by the community

this patch fixed my problems with domain_theme too.
setting rtbc and rising prio due to so many voices.

vomitHatSteve’s picture

vomitHatSteve commented

+1 to Sirviejo's patch

I spent all day yesterday debugging (and unsuccessfully Googling) this. I actually logged in to submit a new ticket suggesting this fix after I finally figured it out this morning!

vomitHatSteve’s picture

vomitHatSteve commented
Status: Reviewed & tested by the community » Needs work

Hold up, I don't think this patch quite works. I just discovered that if you go to a page that should have the admin theme as a non-admin user (e.g. anonymous), it displays the admin theme. This could obviously result in some pretty severe information leaks.

Near as I can figure, the fix is to add || !$GLOBALS['custom_theme'] to the if switch the patch adds.
i.e.

-    if ($GLOBALS['custom_theme'] == variable_get('admin_theme', '0')) {
++    if ($GLOBALS['custom_theme'] == variable_get('admin_theme', '0') || !$GLOBALS['custom_theme']) {

I also added || !$GLOBALS['custom_theme'] to the if switch at the bottom of the function to prevent admin theme from overriding custom_themes set by earlier modules.
i.e.

-  if ($admin_theme) {
+  if ($admin_theme && !$GLOBALS['custom_theme']) {
mikl’s picture

mikl
Location Møn
commented
Status: Needs work » Closed (duplicate)

This is a duplicate of #803866: Doesn't work with modules that also alter $custom_theme.

I've created a new patch that adresses #9 that you can find there.