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.
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
Comment | File | Size | Author |
---|---|---|---|
#2 | admin_theme.module.patch | 782 bytes | sirviejo |
Comments
Comment #1
davyvdb CreditAttribution: davyvdb commented#508536: play nice with $custom_theme
Comment #2
sirviejo CreditAttribution: sirviejo commentedI 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.
Comment #3
afox CreditAttribution: afox commented+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.
Comment #4
sirviejo CreditAttribution: sirviejo commentedhow about my fix in #2 does any contrib be able to test it?
Comment #5
afox CreditAttribution: afox commentedFix #2 worked for me when I had problems with domain_theme.
Comment #6
sirviejo CreditAttribution: sirviejo commentedin my case the problems happens with mobile_tools
Comment #7
geek-merlinthis patch fixed my problems with domain_theme too.
setting rtbc and rising prio due to so many voices.
Comment #8
vomitHatSteve CreditAttribution: 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!
Comment #9
vomitHatSteve CreditAttribution: vomitHatSteve commentedHold 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.
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.
Comment #10
mikl CreditAttribution: mikl commentedThis 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.