[development] Move multiple theme per site support to contrib module

[Adrian Rossouw]

On 06 Jun 2006, at 5:59 PM, Jenny Hsueh wrote:

>
> but having the notion of "enabled" and "default" theme is essential  
> to us, we use groups on our sites and having the ability for each  
> group to choose their own theme seems a kicker, people feel that's  
> a space belong to themselves.  If there are  other ways to achieve  
> the same result it will be fine, but we don't want to lose the   
> user specified theme capabilities  -- i.e. make sure the contribute  
> module for multi-theme support is available at the same time when  
> it disappears  from the core.

Well. I'd like to see the multi-theme support module in contrib be  
done 'right (tm)'.

Please forgive the terminology I am going to be using , the confusion  
is due to the views module coming into existence.
This is one of the two ideas I have that could both conceivably be  
called 'views'. (the other being the V, from the mvc pattern that  
fapi is moving us towards).

Here are some pics i made up a long long time ago, about how i feel  
it should be done.

Essentially the combination of theme selection + configuration  
settings + block layer (+ additional theme config modules) = a  
'view' , or a 'layout' or a 'section'. I will use 'views' in this post.

Basically underneath the hood, the admin/display page is actually  
just configuring the default view. When you install the multi-view  
module, you get a new menu item, which opens to a page
like this :

http://drupal.org/files/issues/Picture%202.jpg

Each one of these views is exactly the same as the default view, with  
exactly the same options. Except each of these views has a 'weight' ,  
and a set of rules that need to match for
it to be selected. Any module can create rules. Some basic ones would  
be based on date, based on role , based on OG .. whatever.

The view's rules get configured via an interface (http://drupal.org/ 
files/issues/Picture%203.jpg) that's almost exactly like your web  
browser.

Ideally, I would like to see this kind of interface completely  
supplant the n*count($themes) + m*count(blocks) + o*count(throttle  
settings) + p * count(possible sections module  
config) ... ... ... ... ...
which all have weird interdependent ways of changing exactly what you  
are going to see on your site.

Additionally, we can ship with a special 'admin' view, pre- 
configured, that can't be modified, unless you have the multi-view  
module enabled, in which case you can adjust it at leisure.

Also part of this, now that every 'view' is just a collection of  
settings, stored in the variables table, is the possibility to spawn  
one of these config pages for every user blog for instance,
or per user. The loading would happen in exactly the same way we have  
the $custom_theme loading now, so we wouldn't be making the interface  
unusable.




















--
Adrian Rossouw
Drupal developer and Bryght Guy
http://drupal.org | http://bryght.com