site switches out of admin theme...

This is true and easy to replicate and happens with Firefox too. So I think it's not releated with the platform or browser cache.
Therefore I mark this as critical.

I don't think this is a critical bug, as this is only a display issue on the admin side. But I have noticed this as well. Simply set an admin theme and go to admin/build/block and you'll see the main site theme, not the admin theme.

Looks like this is by design for the block admin page as it switches to whatever theme you're configuring blocks for. Is this happening anywhere else for anybody on the nightly snapshot of Drupal 5.x-dev?

More on this...
if you're administration theme is disabled in site building->theme there's no way to change the block settings of it.

IMHO even if this bug can't be considered critical it makes this feature pretty ugly to use.

It is best to keep this issue to the theme switch on mysite.com/admin/build/modules. The theme switch on admin/build/block is by design, the editing of blocks for the administration theme is addressed in http://drupal.org/node/103717.

I couldn't reproduce this on a minimal core installation. However, when views (for example) is enabled, the theme system is initialized prematurely during rebuilding of the menu:

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.

Note that dropping out of the administration theme will happen any time a module with a lower weight (or alphabet and similar weight) causes theme() to run in hook_menu(FALSE).

We may need to move the admin theme detection to init_theme().

Hi,

The same issue experienced here with an installation of Drupal 5.1.

As I'm not a programmer at all, this might sound pretty stupid, but can it be that the path and/or URL alias has something to do with this?

Everything seems to be fine as long as the path sticks to:
- example.com/en-US/admin/...

However, there's a problem as soon as the path becomes something like:
- example.com/en-US/node/add
- example.com/en-US/node/1/edit/...

At least, that's what I see for now.

I remember having the same kind of challenge when using sections module in 4.7.4. At the time I used this module to create the same kind of functionality by defining an admin section and assigning an admin theme to it. However, as the assignment was based on the paths being defined, it was not as easy as just assigning the path:
- /admin*

Hope this helps. Would be great if this info can be useful...

Cheers,
Marc

Has there been any progress on this? I'm running Drupal 5.1 and I'm showing the same problem as New Oceans.

For me, the biggest problem with this bug is that, aside from impacting the admin/build/blocks and admin/build/modules paths, it also impacts the content editing mode - which is the one place where I think most people would want the admin theme applied.

I don't feel comfortable pushing this to critical (since I'm new to the community and don't know the etiquette), but it definitely seems like it should be.

Solved it with this book page:
- http://drupal.org/node/122578

Not sure yet whether all admin pages get the right theme with this or not.

Found two related and therefore maybe useful other pages:
- http://drupal.org/node/45951
- http://drupal.org/node/46027

Haven't tried and I'm not a programmer, so can't say anything about Drupal 5.x compatibility.

Duplicate of http://drupal.org/node/100393. Only considers switching on admin/modules submission, not the node edit pages btw, which is an entirely separate subject.

Ok.

But what about node > add and node > edit pages then?

I am running a site on 5.x, with Garland as the admin theme, and Zen as the general site theme.

When an admin page (blocks, modules, settings, or anything else) is loaded by the system (i.e. a form is submitted, a custom module runs and uses a drupal_goto), the page loads with the general theme (Zen) instead of the selected admin theme (Garland). If you refresh the page, it reloads with the correct admin theme.

I have had the same problem with pretty much every general/admin theme combination for a long time.

It's not just a cosmetic issue. One of the main reasons to have a seperate admin theme from a site theme is that the site theme may be heavily modified and not make certain drupal elements available, or may have items that need to be available to end users, but which conflict with back-end administrative display. Sometimes, your user theme simply _can't_ be used on the admin side.

In my case, every time I make an administrative change - settings, modules, blocks, custom stuff, I have to reload the admin pages _every single time_ before I can do other work.

Coyote: that's probably an issue with one of the module you installed. It works perfectly on a number of Drupal installation out there...