[drupal-devel] [feature] move user-selected themes out of core
TDobes
drupal-devel at drupal.org
Mon Aug 22 04:19:15 UTC 2005
Issue status update for
http://drupal.org/node/26302
Post a follow up:
http://drupal.org/project/comments/add/26302
Project: Drupal
Version: cvs
Component: theme system
Category: feature requests
Priority: normal
Assigned to: TDobes
Reported by: Torenware
Updated by: TDobes
Status: patch (code needs review)
Attachment: http://drupal.org/files/issues/usertheme.module.txt (3.06 KB)
Here's a quick copy-and-paste module containing the code removed from
core... it allows users (whom are granted the appropriate permission)
to switch the theme with which they view the site.
I made it as a proof-of-concept that this same functionality can easily
be recreated by a standalone module.
TDobes
Previous comments:
------------------------------------------------------------------------
Mon, 04 Jul 2005 01:50:45 +0000 : Torenware
Attachment: http://drupal.org/files/issues/add-user-themable-option.diff (1.86 KB)
>From the forum thread How To Prevent Users From Changing The Theme. I
asked:
"
I'm working on a module that uses organic groups. I want to allow
different groups to choose different themes, but I don't want
individual users to have that capability.
I'm assuming that this is easy to do, but I can't find a setting. Can
anybody point me in the right direction?
Thanks,
Rob
"
At sepeck's suggestion, I'm submitting a patch to do this. It's
against 4.6.0, and modifies theme.inc and system.module. It creates a
variable 'configurable_user_themes' which defaults to "enabled"
(4.6.0's current behavior), and if activated, makes system.module
remove the UI for selected a theme, and also causes theme.inc to ignore
any setting for $user->theme if it exists.
------------------------------------------------------------------------
Mon, 04 Jul 2005 01:54:40 +0000 : Torenware
Attachment: http://drupal.org/files/issues/add-user-themable-option_0.diff (1.86 KB)
Didn't set this to "patch" initially, so I'm including the patch again.
Not sure what the procedure is just yet.
------------------------------------------------------------------------
Mon, 04 Jul 2005 05:07:44 +0000 : TDobes
-1 -- sorry, but I feel that we should use a different method for this
sort of thing. Any theme that is checked in the admin-> themes screen
should be selectable by users. Modules should get their list of
available themes from list_themes(), which provides a list of all
available themes, not just those that are selected for use by users.
------------------------------------------------------------------------
Mon, 04 Jul 2005 09:21:57 +0000 : Bèr Kessels
I think we should simply rename the "enabled" into "selecatble". Or any
better term.
For the only thing tha checkbox does is enable it for users to select.
It does not enable or disable the theme at all.
------------------------------------------------------------------------
Mon, 04 Jul 2005 18:56:53 +0000 : Torenware
A couple of comments:
To TDobbs: for most applications, you're right. But for some
applications where it's important to the site that user experience is
well tested, letting individual users set the theme is something of a
nightmare; a problem with the theme is perceived as a problem with the
site. So for /those/ sites (such as the one I'm currently working on),
letting the user set the theme was APITA.
Still, for a community site, I agree that the current behavior is fine.
So I made the current behavior the default.
To Bèr Kessels: Let me see if I understand what you mean.
Currently, I've coded the UI to say in its English default:
User theme settings
Configurable Themes:
* Disabled
* Enabled
Enable or disable user-configurable themes. When enabled, users can
set their own theme to override the site's default theme.
Would you prefer:
User theme settings
Selectable Themes:
* Disabled
* Enabled
Enable or disable user-selectable themes. When enabled, users can
select their own theme to override the site's default theme.
I don't really want to lose the "Disable"/"Enable" part, because if you
look at the current UI in 4.6, all similar settings are done that way.
So using a checkbox would be inconsistent with the rest of the page.
How's that?
Rob
------------------------------------------------------------------------
Mon, 04 Jul 2005 21:31:14 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/theme.png (17.19 KB)
you indeed misunderstood me.
We have a "enable theme" checkbox in the theme overview. That checkbos
*does not enable anything* it only gives users the opportunity to
select that theme.
Please se the screeny (sorry, Dutch locale enabled) for what I mean. Th
e second comumn. That chackbox. Just investigte its use. You will its
complete and utter cruft, that checkbox.
Ber
------------------------------------------------------------------------
Mon, 04 Jul 2005 23:20:55 +0000 : Torenware
Ber,
I have a site that may well use themes set at the group level, so
unactivating the theme via admin/theme is not a great solution for me.
The problem with your solution is that if a theme is deactivated, it is
not available for anyone.
I need multiple themes available, but need to make the rather confusing
UI that appears in user/n/edit to go away. Your options will not do
that.
------------------------------------------------------------------------
Mon, 04 Jul 2005 23:28:27 +0000 : Torenware
Ber,
/Please se the screeny (sorry, Dutch locale enabled) for what I mean.
Th e second comumn. That chackbox. Just investigte its use. You will
its complete and utter cruft, that checkbox./
I'm not following you. Could you please explain a bit more?
Thanks,
Rob
------------------------------------------------------------------------
Mon, 04 Jul 2005 23:37:13 +0000 : TDobes
/I have a site that may well use themes set at the group level, so
unactivating the theme via admin/theme is not a great solution for me./
Sure it is! Deactivating themes in admin->theme removes them *ONLY*
from the list of themes available for users to select. It should not
remove them from the list of available themes for modules to use (via.
the $custom_theme variable). If themes are disappearing from the
modules' lists, these are bugs in the modules and should be reported
elsewhere.
I was under the impression that you were writing your own module, which
is why I suggested you use the list_themes function. This function
returns all available themes, not just those that are selected in
admin->themes.
Ber has mentioned that the term "enabled" is poorly chosen and should
be replaced with something else, such as "user-selectable". I agree
with him.
/The problem with your solution is that if a theme is deactivated, it
is not available for anyone./
This is completely false. It is not available to be chosen in the "my
account" screen, but it is still very readily available for use by
modules through the $custom_theme variable.
/I need multiple themes available, but need to make the rather
confusing UI that appears in user/n/edit to go away. Your options will
not do that./
Yes they do. How are you determining the list of available themes in
your module? If the themes are disappearing when you deselect them
from admin->themes, then your module is working improperly.
------------------------------------------------------------------------
Mon, 04 Jul 2005 23:59:25 +0000 : Torenware
OK, if I'm understanding you, then indeed the UI in admin/themes is bad
done enough to fool a native English speaker. What y'all from Europe
make of some of the terms, I can't even guess :-)
I'll see if the UI disappears if all of the items are "deactivated"
makes the UI go away (and doesn't break Organic Groups...). But it
sounds like the real "bug" is in the documentation. This string:
/
Select which themes are available to your users and specify the default
theme. To configure site-wide display settings, click the "configure"
task above. Alternately, to override these settings in a specific
theme, click the "configure" link for the corresponding theme.
/
needs changing. Perhaps something like "Choose a default theme for
your site, and select which themes your users can choose to override
the default."
For the record: I do not have a clue what "Alternately, to override
these settings in a specific theme, click the "configure" link for the
corresponding theme.". If someone will tell me what that means, maybe
some of us can translate it into English :-) Then someone can translate
it into whatever else we need to support.
------------------------------------------------------------------------
Sat, 20 Aug 2005 05:22:53 +0000 : TDobes
Please see the patch I've attached to this issue [1], which renames
"enabled" to "user-selectable"... this should hopefully clear up a lot
of confusion.
[1] http://drupal.org/node/29002
------------------------------------------------------------------------
Sat, 20 Aug 2005 07:52:28 +0000 : robertDouglass
I'd like to propose a different solution; create a "can select own
theme" permission for users.
I agree that there are cases where some people should be able to choose
their theme and others shouldn't. Personally, I don't make many sites
where you get to "skin" the site just for fun. More likely, I use theme
selection for development purposes (I develop the next version of a
site's theme and can switch back and forth, and so can the developer,
but nobody else).
If we had a permission that could be given to roles, then og group
administrators could be given this permission, if I'm not mistaken.
Would this fit the bill, Torenware?
------------------------------------------------------------------------
Sat, 20 Aug 2005 17:30:29 +0000 : Bèr Kessels
personally I am all for removing that option alltogether. "for
development reasons" is simply not a reason to leave this in.
What about getting rid of this "let users select their alternative
theme". And focus more on sections/themeswitchers ?
------------------------------------------------------------------------
Sat, 20 Aug 2005 18:52:03 +0000 : robertDouglass
I'm not for removing it. There are a lot of efforts going forward to do
things like theme an individual's blog differently (blog_theme module,
I think), and this is very interesting, especially if combined with
some form of theme editor. The best interface we have for choosing
themes is part of the user edit page. Let's not get rid of it. What's
wrong with an permission to allow users to choose their own theme?
------------------------------------------------------------------------
Sun, 21 Aug 2005 08:56:32 +0000 : Bèr Kessels
There is nothnig wrong witha permission. But with the options in your
profile.
* Does anyone actually allow his users to choose his or her theme in
the profile? I have never come across a drupal site that does this.
Never!
* As you state, there are loads of much better uses of personal themes,
like letting a user choose a theme for his blog. Or a print theme, or a
theme for better visibility. Or even a theme special for bots.
sections, admin themes, etc.
None of these cases benefit from the in-profile theme choice.
I think this is some odd *nuke ripoff feature, that is only there,
because no-one took the time to remove it. Really, have you ever seen
this being used on a site?
So to conclude: IMO the in-profile theme choice should go. We should
focus on writing or improving modules that do advanced themeswitching.
------------------------------------------------------------------------
Sun, 21 Aug 2005 09:07:02 +0000 : robertDouglass
Ok, I agree that the in-profile theme changing stuff is cruft. Better
would be a module that lets users do this. It could even show up in the
same place, but at least it wouldn't be in core.
------------------------------------------------------------------------
Sun, 21 Aug 2005 09:13:59 +0000 : TDobes
In response to Bèr:
"* Does anyone actually allow his users to choose his or her theme in
the profile? I have never come across a drupal site that does this.
Never!
"
Well, I use the feature. In fact, it was the reason I got interested
in the Drupal theming system to begin with. I was extremely frustrated
by users' inability to switch between chameleon styles and xtemplate
templates in Drupal prior the the last major theming patch.
However, I tend to agree with you that this feature could be removed
from core. This sort of functionality could be added to the user
profile page by a contrib module and implemented by using the
$custom_theme variable.
------------------------------------------------------------------------
Sun, 21 Aug 2005 21:37:56 +0000 : Dries
Agreed. Let's move this to a contributed module and let's tidy up the
theme configuration page (unless I'm mistaken, the enabled-checkboxes
could probably be removed?).
------------------------------------------------------------------------
Sun, 21 Aug 2005 21:43:23 +0000 : killes at www.drop.org
Moving to cvs. I am delighted about this change.
This "feature" annoyed me right from when I started to use Drupal...
------------------------------------------------------------------------
Mon, 22 Aug 2005 04:14:48 +0000 : TDobes
Attachment: http://drupal.org/files/issues/no_more_user_selectable_themes.patch (5.39 KB)
I've attached a patch which removes the option for selecting themes from
the _user hook and the special handling of $user->theme from init_theme.
While I did consider removing the "enabled" field, I decided against
it. When all themes are always enabled, the number of sub-tabs of
"configure" can become unmanagable. drumm's recent usability
improvement [2] to the theme admin involved hiding tabs for those
themes which are not enabled. Additionally, contrib modules which
manipulate $custom_theme should be obtaining their list of selections
by using list_themes(). Therefore, they too would benefit by
displaying only those themes which have been enabled by the site admin.
For example, a site admin may wish to make only certain themes
available to other site developers who have the ability to switch
themes in certain sections of the site.
[2] http://drupal.org/node/29002
More information about the drupal-devel
mailing list