[development] Move multiple theme per site support to contrib
adrian at bryght.com
Tue Jun 6 17:00:41 UTC 2006
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 :
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
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
Drupal developer and Bryght Guy
http://drupal.org | http://bryght.com
More information about the development