Move multiple theme per site support to contrib module
I was playing with theme stuff again, and I realised how completely sub-optimal the current configuration is. How many people actually use user specified themes on their sites? This is the kind of functionality that only really clutters up the default interface, and confuses a lot of people for no good reason. We should simply remove the 'enabled' checkbox, and rename the default radio to 'enable'. This removes a chunk of code , and all this can very easily be done via _form_alter now, for those that need it. What I would also like to see , is that we re-organise the the admin as follows : admin display theme (default tab) regions (tab, ie: what admin/blocks used to be) settings (tab) Also. completely getting rid of the tiered theme setting stuff, and only having one set of settings, per theme (same with the block) I do believe that the block / region settings are very much a display issue. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Also. completely getting rid of the tiered theme setting stuff, and only having one set of settings, per theme (same with the block)
While we're on the subject of settings, I suggest giving themes more control over their settings. Something like hook_settings would be perfect, in fact. Let the theme designer implement a hook in template.php (for the PHPTemplate engine anyway, some other included code for other theme engines). Use case: A theme that allows users to specify the widths of columns and then generates a dynamic or cached CSS file. Right now, the only way I could find to do this was to have a combination module and theme. -M
We should simply remove the 'enabled' checkbox, and rename the default radio to 'enable'.
This then causes problems for useful configurations, I'd think, like "theme this section differently" (sections.module) or "theme admin differently than the rest of the site" which, I think, both assume that the themes available are those that are enabled. -- Morbus Iff ( masochism-oriented recombinant bot (unlisted series) ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
We should simply remove the 'enabled' checkbox, and rename the default radio to 'enable'.
This removes a chunk of code , and all this can very easily be done via _form_alter now, for those that need it.
all this makes good sense to me. nice.
On Tue, 06 Jun 2006 17:29:49 +0200, Moshe Weitzman <weitzman@tejasa.com> wrote:
We should simply remove the 'enabled' checkbox, and rename the default radio to 'enable'. This removes a chunk of code , and all this can very easily be done via _form_alter now, for those that need it.
all this makes good sense to me. nice.
BTW. Eaton is working on making the admin pages themability problem. Stay tuned!
Indeed I am. Those interested in theming stuff (and especially those familiar with phptemplate), please check out http://drupal.org/node/65706. It introduces a new way to override page templates in the same way that the default 'node' template can be overridden by node-story.tpl.php. It doesn't break compatability with existing page.tpl.php and $variables hacks, but makes it much, much simpler for themers to drop in alternate layouts for, say, the admin page, the front page, and the 'default' page without resorting to any other code. --Jeff
-----Original Message----- From: Karoly Negyesi [mailto:karoly@negyesi.net] Sent: Tuesday, June 06, 2006 2:48 PM To: development@drupal.org Subject: Re: [development] Move multiple theme per site support to contribmodule
BTW. Eaton is working on making the admin pages themability problem. Stay tuned!
I don't like the idea of getting rid of the "enabled" idea. Almost every site I make I have used this feature early on to test an preview themes with users. It is also handy for rolling out new themes and testing them. There is also one site I do use it on and another I plan to release. Enough personal experience, looking at it from a community perspective. When you roll out a large corporate sort of site you're right this does seem pointless. It however does come to the time where you will need a new theme for that site. Even after testing it offline, I personally would test it on the main server as a test user with rights to change theme. Now, on a more community driven site or a hobbyist site this is going to show up being used more often. These are also the people that aren't going to want to trudge around the contrib modules to find something like this. A lot of them are also probably going to get fed up and find a way to have a less functional site with something simple like phpBB(its method for this is more confusing by far though). So, both types of sites have use cases for this functionality. To me, removing this doesn't add any bonuses but leaving it in provides some useful features. I also think its a simple clean cut interface and I really don't think it confuses anybody. I immediately understood what was going on when I saw the page. The tiered settings on the other hand are confusing. I think there was some discussion about this prior to the 4.7 release as well. I'd be interested in seeing some work there though I'm not sure of a the right approach. James Gilliland
Whatever you do, keep the $custom_theme global variable working the same way it does today. This way, contrib modules can make use of it to display per-user, per-section, or per-path themes.
I like the idea of grouping the theme and block/region admin functions together. 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. Thanks Jenny Adrian Rossouw wrote:
I was playing with theme stuff again, and I realised how completely sub-optimal the current configuration is.
How many people actually use user specified themes on their sites? This is the kind of functionality that only really clutters up the default interface, and confuses a lot of people for no good reason.
We should simply remove the 'enabled' checkbox, and rename the default radio to 'enable'.
This removes a chunk of code , and all this can very easily be done via _form_alter now, for those that need it.
What I would also like to see , is that we re-organise the the admin as follows : admin display theme (default tab) regions (tab, ie: what admin/blocks used to be) settings (tab)
Also. completely getting rid of the tiered theme setting stuff, and only having one set of settings, per theme (same with the block)
I do believe that the block / region settings are very much a display issue.
-- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
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.
if you are referring to organic groups module, then it will surely continue to offer theme choice among the non enabled themes. no worries.
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
On Jun 6, 2006, at 7:49 AM, Adrian Rossouw wrote:
I do believe that the block / region settings are very much a display issue.
i don't feel too passionately about this, so please ignore if this is a viewpoint of a tiny minority, but i consider blocks to be content, and themes to be how the content looks. i really like the separation of content from presentation that drupal + the theme layer maintains. sure, a lot of the content in blocks can be viewed by other means, but not all of it. some things can only be done via blocks, and i think of deciding what blocks to enable and how they should behave as making decisions about what content should be available on a given page. what the blocks *look* like is a job for the theme layer, and therefore, something i usually don't care about at all. ;) personal bias: i mess with block configuration far more often on my site than themes, so -1 to making the themes the default tab and the blocks buried under yet another layer of clicking to access. of course, *where* on the pages a given block goes is more on the presentation side of things, and it'd be far worse to split out these configuration settings for block (1 page at admin/blocks to enable them, and a different page/tag in admin/display to control where they appear -- EVIL!). if the theme-aware among us believe strongly this question of layout is the fundamental aspect of block configuration, and want to group all of this with other display related stuff, i won't object *too* loudly. ;) final thought: drumm (for good reason) already thinks the block admin pages are too busy and cluttered as they are. perhaps splitting out some of that stuff into sub-tabs would make the whole thing easier to manage. moving admin/blocks to a tab on /admin/display would probably make this problem worse. again, i don't want to generate flames about this, so if everyone thinks i'm crazy, i'll go away on this thread. ;) but, i wanted to at least raise some counter-arugments while we're considering this change. thanks, -derek (dww)
Adrian Rossouw wrote:
How many people actually use user specified themes on their sites? Not me, not 'users' as such anyway. I do use this functionality when making new themes though. The admin account gets it's theme set to a working theme, whilst anonymous and themedev users get the default new-theme-in-progres-which-might-be-broken.
It's not hard to come up with other uses either - suppose I want to test a new theme on a live site? This is a good feature, I'm sure we'd get by without it, but... Move it to a separate module? Maybe. To contrib? Everyone always fears a module moved there will languish. Ditching global theme settings and moving to per theme only seems like a good simplifying idea though. -- Adrian Simmons (aka adrinux) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@perlucida.com>
On 6/6/06, Adrian Simmons <adrinux@perlucida.com> wrote:
Adrian Rossouw wrote:
How many people actually use user specified themes on their sites?
Not me, not 'users' as such anyway. I do use this functionality when making new themes though. The admin account gets it's theme set to a working theme, whilst anonymous and themedev users get the default new-theme-in-progres-which-might-be-broken.
I use the feature similarly. Anonymous users get a "pretty" site theme that doesn't display the admin or editing features correctly and authenticated users get bluemarine. I seem to remember that the difficulty of theming the admin pages was listed as one of themer's biggest frustrations in one of those admin surveys. andrew
Adrian Rossouw wrote:
How many people actually use user specified themes on their sites? This is the kind of functionality that only really clutters up the default interface, and confuses a lot of people for no good reason.
We should simply remove the 'enabled' checkbox, and rename the default radio to 'enable'.
On the contrary, I greatly dislike the feature and pushed for the patch that made it a permission that had to be granted. No websites that I have built, and none that I visit regularly, let users choose their theme. 1++ for moving it into contrib. -Robert
On 6/7/06, Adrian Rossouw <adrian@bryght.com> wrote:
How many people actually use user specified themes on their sites? This is the kind of functionality that only really clutters up the default interface, and confuses a lot of people for no good reason.
Agreed. +1 from me for moving user-specified theme stuff to contrib. But as some people have made clear in this thread, this is a feature that DOES get a reasonable amount of use, so if/when it moves to contrib, it really does need to be properly maintained. I guess that if it really is needed by some people, then those people will ensure that it stays maintained ;-) (don't look at me).
What I would also like to see , is that we re-organise the the admin as follows : admin display theme (default tab) regions (tab, ie: what admin/blocks used to be) settings (tab)
Also. completely getting rid of the tiered theme setting stuff, and only having one set of settings, per theme (same with the block)
I do believe that the block / region settings are very much a display issue.
My initial reaction to this was "Nooo! Not more mouse clicks! Not more nested admin pages! Usability nightmare!" However, if this change is absolutely needed to bring in a new "display view system" (which I'm sure I will like, once I've worked out what it is :-p), then it certainly becomes more justified. Dries has indicated that the #1 priority for Drupal 4.8 is usability improvements (esp. for admin pages), so if this adversely affects admin usability at all, then -1 from me. Also, I think that this discussion has made the issue of semantics one that needs to be urgently resolved. In particular, as Adrian has pointed out, we need to settle the use of the word "view". Here's my take on the matter: - The views module has become very popular. IMO, the word "view" is 'taken' by the views module, for better or for worse. When people think of a view in Drupal, they think "custom node listing". Therefore, giving the word "view" a second definition (associated with themes) is a bad move, and will just lead to confusion. - If we introduce a new "display view system", where you can associate theme(s), block settings, etc with a particular "display view", then we need a new name for that system. - We should change the definition of a "theme" within Drupal (haha - how hypocritical of me, we can change the def. of 'theme', but not of 'view'!). A "theme" can now be the name for a "display view". You will be able to associate [what is now called a theme], and blocks / regions / settings, to each "theme". - What is now called a "theme" gets renamed to something else. My suggestion is "skin". Why change the definition of the word "theme" in Drupal? The word "theme" is more of a general / all-encompassing word, in the dictionary sense, and in the computer sense. In MS Windows, for example, a "theme" is: "a background plus a set of icons, sounds, and other elements to help you personalize your computer". The word "skin", OTOH, is more specifically related to visual display, colours, positioning, etc. If we add a new logical level to the display system in Drupal, then "theme" should be the top-level general entity, and "skin" (or some other word) should be the specific look-and-feel entity that can be associated with one or more themes, and perhaps configured differently per-theme. On a related topic, if we introduce this new layer, then when the 'select different theme' option is enabled, users should be able to select a different theme in the "new all-encompassing" sense, i.e. they choose a theme, not a skin. So when they switch themes, all the settings for blocks and other things change accordingly to match it. What do other people have to say on this difficult issue of semantics and word definitions? Cheers, Jaza.
On 07 Jun 2006, at 2:14 AM, Jeremy Epstein wrote:
- The views module has become very popular. IMO, the word "view" is 'taken' by the views module, for better or for worse. When people think of a view in Drupal, they think "custom node listing". Therefore, giving the word "view" a second definition (associated with themes) is a bad move, and will just lead to confusion.
Yes. It being called views is unfortunate. As it's actually a listings api =) When the core query builder and the like gets into core, I also recommend it be called that =). The display view is even not my favorite use for the word. The next version of FAPI will have clearly delineated MVC boundaries. Calling the view (node views, summary views etc) anything but 'view' is a big problem for me =)
Why change the definition of the word "theme" in Drupal? The word "theme" is more of a general / all-encompassing word, in the dictionary sense, and in the computer sense. In MS Windows, for example, a "theme" is: "a background plus a set of icons, sounds, and other elements to help you personalize your computer". The word "skin", OTOH, is more specifically related to visual display, colours, positioning, etc. If we add a new logical level to the display system in Drupal, then "theme" should be the top-level general entity, and "skin" (or some other word) should be the specific look-and-feel entity that can be associated with one or more themes, and perhaps configured differently per-theme. I like that thinking =)
-- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On 07 Jun 2006, at 15:54, Adrian Rossouw wrote:
- The views module has become very popular. IMO, the word "view" is 'taken' by the views module, for better or for worse. When people think of a view in Drupal, they think "custom node listing". Therefore, giving the word "view" a second definition (associated with themes) is a bad move, and will just lead to confusion.
Yes. It being called views is unfortunate. As it's actually a listings api =) When the core query builder and the like gets into core, I also recommend it be called that =).
No one is working on that, AFAIK. Work towards integration of the CCK is also absent (minus a patch from Karoly). -- Dries Buytaert :: http://www.buytaert.net/
Op dinsdag 6 juni 2006 16:49, schreef Adrian Rossouw:
I was playing with theme stuff again, and I realised how completely sub-optimal the current configuration is.
How many people actually use user specified themes on their sites? This is the kind of functionality that only really clutters up the default interface, and confuses a lot of people for no good reason.
We should simply remove the 'enabled' checkbox, and rename the default radio to 'enable'.
This removes a chunk of code , and all this can very easily be done via _form_alter now, for those that need it. What I would also like to see , is that we re-organise the the admin as follows : admin display theme (default tab) regions (tab, ie: what admin/blocks used to be) settings (tab)
Also. completely getting rid of the tiered theme setting stuff, and only having one set of settings, per theme (same with the block)
I do believe that the block / region settings are very much a display issue.
Good proposal. A few sidenotes: * As long as we keep the posibility to swap themes with an API, or by changing a SESSION var, I see no problems. Adrian S can still develop / test his themes, but should use a (new, yet to be coded) feature in themedev.module. People can still set admin themes, mobile themes and so with modules such as print_theme.module, sections.modules, etc. * Regions are theme specific, so if you want to proceed this way, you really need to overhaul the regions system to. I would make that two diff. projects * We cuold see to it that a module is developed by somone who thinks the 'my settings theme settings' must remain. user_themes.module? That cannot be hard. :) Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ] Drupal upgrade repareert kritiek beveiligingslek: http://help.sympal.nl/drupal_upgrade_repareert_kritiek_beveiligingslek
Bèr Kessels wrote:
Adrian S can still develop / test his themes, but should use a (new, yet to be coded) feature in themedev.module. That's the second time in the last few weeks I've seen you suggest new features for themedev ;)
So note that I've essentially finished developing themedev. Recently I've found Xyle Scope and Firebug have eradicated the need to use themedev. So unless someone else adopts it there won't be any development beyond the current 4.7 version. But really multi-themes are more than just a theme development feature. -- Adrian Simmons (aka adrinux) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@perlucida.com>
Op vrijdag 9 juni 2006 18:04, schreef Adrian Simmons:
But really multi-themes are more than just a theme development feature.
Yes. But m poiint was that they should not lie in core. But in modules. user_themes.module, themedev.module, themeswitcher.module, print_style.module, group_style.module, sections.module and so on. Why should one of these cases live in core, but not all the others? Hence my +1 to move them to modules. Bèr -- [ End user Drupal services and hosting | Sympal.nl ] Drupal upgrade repareert kritiek beveiligingslek: http://help.sympal.nl/drupal_upgrade_repareert_kritiek_beveiligingslek
participants (16)
-
Adrian Rossouw -
Adrian Simmons -
andrew morton -
Bèr Kessels -
Derek Wright -
Dries Buytaert -
James Gilliland -
Jeff Eaton -
Jenny Hsueh -
Jeremy Epstein -
Karoly Negyesi -
Khalid B -
Mark Fredrickson -
Morbus Iff -
Moshe Weitzman -
Robert Douglass