Hi, I have done a bit of work in this area for a client, and basically what happens is that you can change the $custom_theme at time time up until the first theme() is called. When the first theme() is called it will run the theme_init() which will load the theme. So it will look at $custom_theme and other places and load it. The problem that I found a lot of contrib modules during hook_menu() will call theme() to do something that is not theme related or add the css to the page, and the theme will be set. The problem is with a lot of contrib modules calling theme() far too early. Gordon. Olav Schettler wrote:
I have written a smallish module (http://drupal.org/project/manage) to provide a separate theme for administration pages. It works nicely by setting $custom_theme and providing some settings for a custom menu and selecting on which pages to apply the theme switch.
I learned how to do all this by looking at the blocks.module. This is also the catch. It doesn't work nicely with blocks.module because selecting the current theme is really done through a set of global variables ($theme, $custom_theme). Once one module has overridden $custom_theme, the knowledge about the original theme (user-specific or standard) is lost.
I currently solve this by excluding admin/block pages from the theme replacement. I have considered to introduce some kind of stack of overridden themes, but as this would affect at least system.module, blocks.module, theme.inc so I wanted to discuss this here first.
Is anybody working on this theme selection right now? This might fall into the realm of Adrian's overhaul of the theming system.
Cheers, Olav