I think you've hit the nail on the head here. This is stuff I personally feel should be relegated to the theme engine or the theme itself. I do a lot of hacks within the theme for a particular site. When you really get down to it we're discussing how to handle presentation, which isn't intregral to the content management process, but is integral to the user experience. A theme switch module which allowed you to choose theme engines/themes based on the view being generated may be fun, but how often on a site do you really need this level of abstraction in the presentation layer? On Thu, 2006-06-22 at 11:13 -0400, Alan Dixon wrote:
A slightly different approach to this kind of problem is to let your theme do all the work - i.e., don't switch themes, just make your existing theme a little more expansive. In fact, the civicspace theme does exactly this - it provides a different look for it's admin pages. You can do this by just some tweaks of your theme, checking what arg(0) is for example, or you can be more aggressively different and use the _phptemplate_variables to make use of a different page template.
I think that the complexity of the discussion that this posting generated is an indicator that modules should avoid trying to fiddle with themes. My understanding of the drupal code is that modules are supposed to create and modify the content in a structured model, and let the theme render it. If modules want to enable sites to provide different looks for pages within their purvue, I think it makes more sense for them to offer some useful themeing functions.
I think that makes more sense both from a code point of view, as well as a useability perspective - switching themes on a user could be extremely disorienting, whereas if you're just working within a single theme, the theme can be more consistent (obviously, it doesn't have to, but at least the responsibility is clearer).
As an example of the risks of theme switching, look here: http://drupal.org/node/65801
- Alan
On 6/20/06, Olav Schettler <olav.schettler@contaire.de> 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
-- Dr. Olav Schettler (Geschäftsführer) contAire GmbH ___________________________________________ Arndtstr. 12 | D-50676 Köln | Germany Office: +49 221 4204757 | Mobile: +49 175 2249141 olav.s@contaire.de | Yahoo! olav ___________________________________________ Please visit our website http://www.contaire.de/