move user-selected themes out of core

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

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.

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

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.

Please see the patch I've attached to this issue, which renames "enabled" to "user-selectable"... this should hopefully clear up a lot of confusion.

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?

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 ?

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?

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.

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.

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.

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?).

Moving to cvs. I am delighted about this change.
This "feature" annoyed me right from when I started to use Drupal...

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

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.

+1 never thought of how easy this would be with $custom_theme.

No longer applies.

There is now an access control to allow users to switch themes or not... does that fix this??

I think that's for the default theme, not individual themes so probably still active.

+1 for this moving to contrib.

bradlis7 is right.