[development] Switching themes in modules

Darrel O'Pry dopry at thing.net
Thu Jun 22 15:59:42 UTC 2006


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 at 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 at contaire.de | Yahoo! olav
> > ___________________________________________
> > Please visit our website http://www.contaire.de/
> >
> >
> 
> 



More information about the development mailing list