Activating modules switches admin theme

I had that problem as well.

I've attached a patch against HEAD.

For the record:

It is cache-related. Under the hood, a redirect to /admin/build/modules is performed after the module configuration is updated, and one would expect to see the same result that one gets when navigating directly to /admin/build/modules (i.e. the admin theme). In practice, different paths are taken through the code for the direct link and the redirect. Presumably the update invalidates some cache or other.

The result is that init_theme() in includes/themes.inc gets called before system_menu() in modules/system/system.module. This means that $custom_theme is assigned too late, and theme_init() is stuck with the default (i.e. non-admin) theme.

The attached patch fixes this by moving the code that checks to see if this is a request for an admin page into init_theme(). It also makes more sense from a where-do-I-find-it? what-does-it-do? perspective for it to be in theme.inc rather than system module.

Don't RTBC your own patch.

Oops, sorry. First patch.

I've attached a patch against 5.1.

does not help for me, activating a module jumps to the main site theme.....

Hi.

Which patch did you apply? And against which version of Drupal?

the 5.1 (http://drupal.org/node/100393#comment-194941) patch against 5.1 cvs

I built the 5.1. patch against the 5.1 tarball. If there's a 5.1. branch in CVS that's been updated since the tarball, or CVS 5.1 refers to the current HEAD, the patch may not have been applied. Also the first patch (against HEAD) uses CVS diff and can be run in place, while the latter (against the 5.1 tarball) uses two different directories and may need to be run as patch -p1 < admin_theme_5_1.patch. Any chance you could check to see if includes/theme.inc contains the words "administrative theme"? If it doesn't then the patch hasn't applied.

Failing that, would it be possible for you to grep through your codebase to see if any other modules are messing with the $custom_theme variable? The only one I could find on my (fairly uncustomized) install was the blocks module, and that case is handled.

tried again (manual apply of patch) and this time it works. Not sure what went wrong the first time.

I can't reproduce this on 5.x with clean urls off, only bluemarine enabled, and garland as the admin theme.

This is actually a duplicate of http://drupal.org/node/100757.

This does indeed not happen on a clean install, but is due to premature theme initialization by t():

As the menu cache has been cleared in the previous step (submitting the modules form), menu_build is called, which in turn calls as hook_menu(TRUE), view_menu, which calls t() with a %variable. This causes t() to call theme('placeholder') which initializes the theme system before system_menu(FALSE) even had the ability to run.

This pre-dates the other bug report and has a patch. Surely the other one's a duplicate?

Marking it as such.

This is still active on 5.1 and while it is easier to reproduce on the modules page i have seen it happen on other admin pages like settings.
I could reproduce it with two sites, one test and one in production.

Furthermore, the current port of the sections module (code works, but still on patches) still suffers from this and makes it highly more critical that it is now.
An admin could safely overlook the theme bumping but for users editing nodes and navigating under multiple themes it becomes something that requires fix.

I haven't tested with the taxonomy theme module or with the various theme changing snippets.
No og based theming was active on those sites. The og function is only for nodes.

Patch seems to work. The site with sections module also work.
I haven't tested extensively, but no side effects arose from the patch alone or from sections.

i confirm that patch from http://drupal.org/node/100393#comment-194941 works well

since this a bugfix for 5.x first and foremost, the 6.x branch may have this bug too.

Currently, we do allow non-enabled themes to be selected as the admin theme and respect this choice.

Changing this restriction would, on some sites, have the effect of changing the admin theme on upgrade without asking or notifying the user. Additionally, the configuration would appear to not work since it would allow non-enabled themes to be selected and not actually change the admin theme.

In HEAD this has moved to system_init(), so I expect that is where it should go in 5.x, without checking if it is enabled.

yes i have 'disabled' garland from available themes, none the less i was able to select it (along with other non-enabled themes) as my admin theme.

the patch from http://drupal.org/node/100393#comment-194941 creates weird effect in the block administration /admin/build/block, whenever i select my custom theme and i do some change and click 'save blocks', it does the change but reverts to my admin theme right away, so if i want to make another change on my default theme i will have to select it again.

FYI, this is still a bug in 5.2 . Activating or deactivating a module in admin/build/modules still causes the non-admin custom theme to be displayed.

Confirmed in 5.3 . Bug still exists.

FYI ... and I guess this makes sense if it's a cache problem ... using the Devel module's "empty cache" link also causes the admin pages to switch themes.

Has there been any progress on this issue? I'm experiencing the same problem using Drupal 5.7

Me too looking for solution. It's kind of silly, this ought to be priority. If ppl gonna use drupal for serious smaller sites they would be most likely to use one theme for admin and other for content, don't see how this bug isn't a priority and hasn't been fixed so far?

So fix it?

well, someone needs to review the code for the side effects.

#17 notes that the list of enabled themes should not apply to the admin theme.
A quick fix will be encasing it within the else of
if (arg(0) == 'admin') { } else { //put it here }
that way it will be effectively skipped for admin themes.

I'm marking it critical because it is indeed possible to have a default theme that interferes with the admin pages.
Besides, the patch have needed review for one year since post #17.
The admin theme is in core so it should not spontaneously revert on every form submit.
Please fix it for the drupal 5.x branch.

The patch still needs to be corrected. The admin theme should not need to be marked as enabled.

I do not think this is critical since nothing is fundamentally broken. Everything works, but sometimes the wrong theme used. Any core theme or well-developed contrib theme is okay.

This should be set as critical. Many themes do not have a wide enough content area to display the content that is produced by some modules, especially Views. There is another bug related to this in Views where the theme only switches to the site theme from the administrative theme when an edited view is submitted, and then only for the first page load after the submission. Seemingly random behavior like this looks pretty unprofessional, in my opinion...

And yes, I've already tried to fix it myself, and have so far failed to do so.

Agreed, the main theme is likely a custom theme, not a core theme.
The set of blocks and menus are different, lack navigation as in a full flash theme or cluttered as in a web portal.
It also breaks the workflow that with every form submit you must return from the main theme to the admin theme to continue the configurations being done.
Even the message area might not be present, and it also affects moderation and troubleshooting to some extent.

Hardcoding the 'admin' path to the admin theme works for me, using the idea on #26
(http://drupal.org/node/100393#comment-752458)

subscribing....

My two cents is that it should be set to critical. I am not a coder or I would be more than happy to lend a hand. I really appreciate all the hard work everyone puts into this, and wanted to say thank you. I am currently developing a site for a nonprofit with many users who not familiar with much other than sending emails. It will be very confusing for them for the admin theme to switch when they are performing backend operations. I have also set the edit paths to the admin theme with the sections module so that it is clear to them when they are editing/managing verses viewing/navigating through the frontend. so for an admin it may not be a huge deal other than an annoyance, but in this case I think it's vital.

I also had a question, and I realize it does not pertain to this topic, but I am having problems finding any posts regarding the issue I'm having. It seems that when content is created/edited that it redirects to the frontpage on submit rather than to the page view of the node. I was just wondering if anyone has had similar issues or could direct me to another forum.

thanks so much,

Jen

I agree that this is critical. I have a trio of simple multisite sites that I was about to deliver to their maintainers. Two of them have pretty, custom-color Garland admin areas. The third one has our simple custom theme applied to the admin area as well.

The admin area requires all sorts of stuff that I haven't included in our theme, so an admin page that has tabs in Garland is broken on the third site because our theme doesn't have tabs. Currently, for example, the only way to add a new user is to remember the URL to do so.

Sure, I could write a ton more stuff for our theme so the admin area works again, but it's still not going to match the other two sites and it's a lot of unnecessary work that's delaying our project. To be honest, I was embarrassed to have to show the site to our people with it in this state--and this error cropped up literally the day before our meeting.

subscribing....
This is one of the most annoying things that drupal does in my opinion. I've learned to live with it for the time being and hoping the bug is fixed. Its also not a very good thing to show a client the admin interface which looks great until you save the modules page or load up the blocks page. I also get the theme switch when submitting custom op forms from within the admin_settings form.

i don't know if i think this is critical, but it is certainly a barrier to folks adopting drupal, as the unexpected switch from theme to theme does look buggy and unprofessional. i've observed this issue on drupal 5.10 sites, with the views module enabled (views is mentioned above as one of the modules that prematurely initializes the theme system). applying the patch (manually) seems to resolve the issue in my testing.

it looks like there's a desire for the patch to allow non-enabled themes to be admin themes. i think that makes sense. removing "&& $themes[$custom_theme]" from the condition in the patch should accomplish that. i'm leaving town today for a week, but i'll test and make an updated patch when i return, unless someone else gets to it first.

Also, some review can be done to ensure other modules don't override the patched code.
For example, i patched a site and got sections module to work, but later got a strange behaviour with taxonomy_theme and even later reintroduced the whole bug with one of those modules to apply a mobile theme.
Thus the core code should be good enough so that module devs use without any need of overrides.

Hello,
Has a working patch been released?
Will this be included in a later revision of Drupal 5.x ?
Thanks,
David

Any news on this? It looks kind of shitty leaving this bug to clients, lying to them saying that the problem is due to some really advanced hardware & software problems which people are working on very hard to fix. Imho this is a critical glitch in the system.

My problems usually starts out when installing to many modules, can't say exactly when it appears but there seems to be some critical mass.

This issue also seems to be related to a problem I've been having with high load, all of a sudden some modules stop working but when the number of online users go down the site goes back to normal. Really strange.

Someone needs to write a good patch for this. This won't get fixed unless someone does the work.

here's the patch i said i'd put together, lo these three months ago. this isn't my code, i just made (what i hope is) an appropriate patch against DRUPAL-5 HEAD. i have tested this in production on a few sites, and it has solved the bug for my purposes. more testing is needed.

I like the direction of this patch, it is good to see someone finally doing some serious work to solve this issue. I like that this patch simplifies 2 sections of code into one. I do have a few changes-

Before, the test was if (arg(0) == 'admin'), now it is if (arg(0) == 'admin' || (arg(0) == 'node' && arg(1) == 'add') || (arg(0) == 'node' && arg(2) == 'edit') || (arg(0) == 'user' && arg(2) == 'edit')). Deciding what is and is not an admin page is a lengthy debate which we should not tackle. 5.x is a stable version and we should keep it as simply admin.

The test for custom theme also changed, $custom_theme && $themes[$custom_theme] ? became if ($custom_theme). This section of code can probably be left untouched.

The new comments should be capitalized and punctuated complete English sentences, line wrapped at 80 characters.

problem is also in 5.x-dev, and we don't want to chase versions.

I'm attaching a version of the patch from #39 that incorporates drumm's comments in #40. This is such an annoying little bug I would love to see the back of it. :)

I've tested the patch at #42 on my own site, and it still doesn't solve the problem. It actually exposes the possibility of losing your block placement data. <long explanation>Say you're on garland and you visit admin/build/block. You get a garland-themed page. Then hit the "Save blocks" button. You get the same problem chocolateboy described in #1. You go through a drupal_goto that sends you back to admin/build/block, but -- this is the important point that chocolateboy was making -- by this point the menu cache has been cleared. So on the new page request for admin/build/block, menu_execute_active_handler() calls menu_get_menu(), which -- because the menu cache is empty -- proceeds to invoke hook_menu($may_cache). If any module on your site uses t() in a $may_cache block, init_theme gets called, and the game is up. You haven't gotten to block_admin_display() yet. So what you see is admin/build/block telling you it's on "garland settings," but themed with your admin theme. If you then, in confusion, click "Save blocks" again, you reassign all your garland blocks to whatever regions exist in your admin theme, and you lose a whole bunch of region placements. I had a site admin do just this yesterday, and boy was he confused.</long explanation>

I think the ideal fix here would be getting contrib modules not to use t() in a $may_cache block. Problem is, a whole boatload of them do it. The actions/workflow combination does it. Advanced forum does it. That's two out of the first five modules in my sites/all/modules directory. There must be a good reason why they need it.

I'm attaching a patch that has init_theme() actually look to see if we're on admin/build/block, and if we are, it refuses to finish executing until block_admin_display() has gotten around to calling it. It works for me but definitely needs some testing; I don't know if there are consequences to running t() without finishing init_theme().

Subscribing... patch from http://drupal.org/node/100393#comment-1192106 seems to work for me

Patch in #43 works for me as well on a 5.16 install. I can replicate the issue by simply enabling or disabling a module and submitting the page. With this patch the theme stays set to the proper admin theme. The code and the comments should be clear to anyone who hasn't read the text of this issue.

I can't replicate on 6.x or HEAD so I'm suggesting (and setting) to RTBC.

This is getting really close. I am a bit worried about simply exiting init_theme() in some cases. I'm worried some detail of block admin may stop working. Maybe the logic from block_admin_display() can be brought into the added code to set $custom_theme correctly there.

Looks like this was fixed in a release since 5.16. At least, I can't replicate it anymore. Given that 5.x is dead, I'm closing this issue.

subscribing

Has anyone experienced this issue with Drupal 6. We're running version 6.22. In three years of Drupal development this is the first time i've run into this issue.
This is the only thread I can find that discusses that issue albeit for D5.

As this thread is closed, i've opened a new D6 issue here: http://drupal.org/node/1278736