[development] Switching themes in modules

Alan Dixon alan.g.dixon at gmail.com
Thu Jun 22 15:13:28 UTC 2006


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/
>
>


-- 
Alan Dixon, Web Developer
http://alan.g.dixon.googlepages.com/


More information about the development mailing list