Remove the per-user themes selection from core

Solid idea. This would be an obvious usability improvement and would only effect a small subset of users.

http://drupal.org/node/293669 is a dup of this.

I agree that this can be confusing, but we use the same logic for languages.

And we already have the administration theme, so there should be at least two themes enabled. And I would go further and say, that any solid web site should have at least 3 themes enabled.
1. Front-end theme
2. Drupal admin theme
3. Site admin theme (as most site owners need only the site specific functions)

So I would leave the multiple-enabled theme support in core and add the Sections module functionality, as I do not understand why only one theme (the Administration theme) has special path settings.

And I agree that the functionality which provides selection of front-end theme by users does not belong to core. The issue title and your explanation seems to be different. So which one should be solved in this issue?

...any solid web site should have at least 3 themes enabled.

Baloney. Design concepts from many (most?) good themes work well both in front end and admin sections. E.g., Garland.

I still don't understand why you would want a non-enabled theme. If you're not using it, take it off the production server. That's a security best practice, anyway.

Pasqualle, alas, we're not at that place yet where pointing out other screens in the Drupal ui is a valid argument for doing things that way, our ui is just nog good enough for that to be true.

And while you agree it can be confusing, you then go on to suggest we even *expand* the functionality here with settings for a third enabled theme? As stated, Drupal core should only include the features needed for the most likely uses. Adding even more features is not a solution to the confusion here.

Besides, Webchick points out that she observed this behaviour multiple times with new users. Can you offer other reasons for your scenario besides "I think it should be…"?

So, +1 from me on removing the 'enabled' option from core.

I will only +1 this *if* we make absolutely sure that a contrib module can restore the functionality. Otherwise, just removing it without ensuring that the proper hooks are in place is a -1.

Here is how a contrib module can do it without adding anything at all to core: in hook_init check your table which stores (uid, theme) and set global $custom_theme accordingly. Adding back the theme selector to hook_user is possible via op form, update and insert.

I think the *problem* is not the feature itself but the UI.

Propose to (at least?) change "enabled" to "Selectable by users".

RE #11: yes, that is exactly what sections module do, but it has an interesting comment:
// only switch to custom theme if theme is active, to prohibit a destroyed site
and it checks for $theme->status == 1
so I am not sure what happens when someone set $custom_theme to disabled theme..

I would like to work with more themes and easily switch between them, and I am not sure how this change will affect the innovation in this field, as I have unfixed issues with the current functionality already..
#316555: Context only knows about the current theme
#340276: ajax view and sections module

Pasqualle: if we remove the UI, we can still make the status column non-unique - then a contrib module can add that back into the form (or add some other UI for it).

Tagging

Issue found in UB2009
When at the theme configuration screen there is an enabled check box for each theme but it isn't clear what enabling multiple themes at the same time will do.

This solution is a remove from core, which obviously takes away the problem, however I do not see that this issue is a compelling enough case from UB2009 to say that we need to remove it, I think other points need to convince that more.

Therefore I am removing the tag, trying to avoid "just remove it" issues to be tagged with UB2009 - as it requires VERY compelling data which we don't have - other then it caused confusion.

@Bojhan I'm adding the tags back in. I disagree as this is a serious usability issue that is compelling enough to change. This functionality is rarely used and is best implemented via a simple contrib module (see catch's comment in #14).

@rickvug Sorry, but please read my comment - the tags are for preserved for UBUserTesting2009(and this issue was not found - nor do we have data on it, in the way projected in the last comments) - whether it is a serious usability issue I did not reject.

I am not talking about whether the solution is good or bad, I am not the one who can usability review this one - wait for all of those to get of the planes.

How about change "Enable" to "Activate", "Default" to "Enable" and leave the code alone?

-1 on removing multiple-enabled theme support. It's useful when creating a new theme for a site next to the old theme, when offering a fixed-wide theme together with a fluid one or some low-bandwidth version for example.

But if (if) multiple-enabled theme support will be removed, what about the block.module who supports different blocks for different themes? Should that be stripped-out as well? Can a contrib-module replace this feature too?

A confusing UI in admin should not be a reason to remove a function from core that is working perfectly well as an essential part of theme support in general.

Rewording of the admin-screen should make it more clear. The help-text talks about 'availability' while the table talks about 'enabled' for example.

#538838: Kill user multitheme support or make it a setting is related but not a duplicate.

Ok, since Damien thinks this is a duplicate (which I still don't agree after reading it up), I'd state my position here:

- Drupal 7 already has two themes enabled by default (Garland and Seven)
- You need to have them enabled so you can configure them
=> two enabled themes in core is a default situation in Drupal 7 core

Removing any kind of support for it would be therefore contrary to what we do otherwise IMHO. However, having user theme selection support is a side effect of enabling the two themes by default for which I've opened #538838: Kill user multitheme support or make it a setting.

If you think these two issues are the same, I can retitle this one. From what I've understood this issue is/was about the themes admin screen (which has nice mocks and videos on some planned work at #491214: implement the top level Appearance / Choose Theme admin page, where single and multiple theme support in terms of the themes themselves and settings are also discussed). However this issue is not about the users profile editing form at all, for which my issue is set up. So should I take over this one, or proceed with the issue I just opened?

What is this issue?

Why do we want to kill a feature that many sites are using! I don't see any strong data saying that only 2% of sites have multiple theme enabled. Drupal is a development platform that is feature rich. Please stop removing powerful features. If we keep removing all the 2% features, Drupal will be less and less the development plarform of choice.

If this lands in Drupal 7, it will effectively kill about half of the sites I'm making, whereas I need to have more than one theme enabled. For example, with Drupal, I can set a main site for artists where each artist have it's theme enabled.

In the user edit account space, that make sense to remove theme switching, but not in the core module page.

What will replace this? Will we need to install multiple Drupal sites?

Please kill this issue. :-)

I think you can just continue with this one, but indeed the title is somewhat misleading. We could easily make it an option, and just avoid bikesheding this untill code freeze. We should probally not optimize for the 2%, but is it worth fighting over?

Taking the ball and changing the title of this issue.

We should only remove the "Theme configuration" collapsible fieldset where the user can select one of the available enabled theme.

So in the end we remove the feature only for the end-user, and we keep multiple-enabled themes for both the site administrator and the site themer et developer.

@xmacinfo, I'm not sure how that's different from what we have now. It's already a permission which can be selected per role, ie. limiting it only to admins/developers.

Well, the other solution is to close this issue as by design. ;-)

This should not be a by design as I've already explained on #538838: Kill user multitheme support or make it a setting. As I've said that issue was focused on the user theme selection and had explanation to that effect, but I can copy that over, if you are more comfortable using this issue for this problem. While Steph argues there is already a permission, the problem in Drupal 7 is that uid #1 can never have that permission revoked and all users with the administrator role have that permission granted by default, so by default they *already* **always** see this selection on their user editing screen, since we have two themes enabled on Drupal 7 by default. This is a new WTF for admin users which we should get rid of. Copying my notes from that issue here:

Now that Garland *and* Seven is enabled in core, we have this interesting situation, where admin users will always get a theme selector screen [on their user edit screen]. [...] This is bad. People should not be able to select the admin theme as a site theme, if they are configured separate. So we can do a few things:

(A) Kill the per-user theme support in core and make it contrib
(B) Make "this theme can be user selected" a setting somehow - gonna be a ugly and complex for the admin but would let admins use different themes for site sections (think themekey module, sections module, etc), while not distracting admins with this screen
(C) Just not display the admin [theme] in this form when it is set explicitly different to the site theme
(D) Just live with the fact. Only user #1 sees this at all times, other admins can have this permission revoked to be able to select themes (but in the admin role it will be granted automatically).
(E) Whatever else?

I'm not sure whether (A) or (C) is the best. I'd not add another magic setting for this.

I'm adding a (F):

(F) Remove the special behavior of uid #1 now that we have an admin role in core.

@Damien: well, that would still require removing the magic of granting *this single permission* for admins, so admins will not need to go and turn it off 99% of the time. Also, now that I think about it the problem with the admin menu being there is also an issue with those sites who would indeed enable this user theme selection feature for their ordinary users. Ordinary users would be able to use the admin theme for their UI. Ouch.

I am seeing that we should exclude the admin theme from the list of selectable themes here and that would limit the number of selectable themes to 1 and remove this WTF. So I'm getting closer to thinking (C) is best.

I suggest we add a admin = TRUE option to theme .info, and hide all themes tagged as"admin" from the user UI.

Thinking about this more, I think we reached the point where the "let the user select the theme" does not make sense anymore as a core feature. There are just too many different use case this UI needs to cover now.

Yeah, and it is not a too serious feature anyway, is it :) How many sites would let users select their theme? Would they do it via this awkward UI on the user edit page. I'd somehow doubt.

It's a feature I use, but then again I do testing of a whole lot of themes ;) I believe a common use case is for developers/administrators (you know, the 90% of the Drupal site building world which doesn't use dev sites, local environments, or VCS) to use this setting for testing a new theme on their site, so it can be switched only for their user for testing purposes before deploying site wide.

That being said, I'd be completely fine with it in contrib. The switchtheme module is popular for this in contrib anyway, which provides a couple of block options.

I agree completely with Gábor comments in #30. The Seven theme brings in another layer.

So, between solutions A through F and #33, what would be best?

fwiw I think we should remove multiple enabled theme support from the UI in general, however the specific issues with uid 1 means we have to do something here. I'd rather we removed the feature than special cased admin themes.

For the UI in general we must keep multiple-enabled themes in core. There are many instances where it's needed. As Gábor explains in [528838]: “Sites might want to have multiple themes switched programatically based on sections of the site [...].”

There are a lot of sites on the net that are using multiple themes, based on section, subject, etc.

Actually the follow-up should have been [528838], kill the feature only for end-users.

All most all sites in the real world like Google's orkut, or Yahoo or Myspace etc allow end-users to choose a theme of their choice. Removing this from core will be a step backwards, and I am afraid this will again have to added as a OOB feature sometime in future.

Drupal sites using this feature and upgrading to 7 will have a bumpy ride, and for fresh installs there will be ohh-yet-another-module to install.

If the competition from Wordpress is seen themes is such a HOT issue Drupal is guaranted to fall a step behind if this well functioning feature is killed.

If the test users have been so dumb as NOT to understand "enabled" and "default" INSTEAD of killing it for, simply add a clear concise statement at the header of the theme picker :
"You must BOTH enable and make default a theme to make it visible as your site's theme. More help >"

kill the feature only for end-users

I really do not understand why this feature has to be killed for end-users.
Or there has to be hassle for the admin to search, download,enable, configure YET another plugin to offer this simple feature to his end-users.

End-users enjoy this feature in some form or other in all most all community, blogging, forum sites
and the theme choosing screen for the end-user is damn, damn easy. Please see the diagram.

There is absolutely NO chance that the end-user can get confused by this INSTEAD he will be confused if he do not find this so-very-common feature.

@kaakuu I can understand that this is a very important feature for you. How common the feature really is comes down to the type of site. I would argue that few community sites support user configured themes but I don't have any hard date to backup my claim. Nor does anyone else. The real issue here isn't removing the functionality but fixing the ass-backwards screen detailed in comment #3 as it confuses many new users. To many here, fixing an interface that 100% of site admins use is more important than whatever % of sites that support user selectable themes. Moving the UI to contrib is one option on the table. If you can think of a better theme selection UI for core that keeps the functionality I'm sure others would welcome the feedback.

For the UI in general we must keep multiple-enabled themes in core. There are many instances where it's needed. As Gábor explains in [528838]: “Sites might want to have multiple themes switched programatically based on sections of the site [...].”

If you're switching something programmatically like that, you don't need a core UI for it - the module doing the theme switch can happily enable and disable themes by itself.

@catch: well, you can only configure enabled themes, so to be able to actually administer/configure those themes, you need to have them enabled. That other magical features become available when you have the themes enabled is the problem. Hacking this by making the other themes disabled is just a hack. You still need to enable the themes to administer them. If you have multiple section themes, enabling them one-by-one to make some settings adjustments sounds crazy. Jeff Noyes suggests at #491214: implement the top level Appearance / Choose Theme admin page, that we should be fine with all the same settings applied to all the enabled themes (which would work around this problem), so we don't need to have settings per themes at all. His goal is a simplified UI, not a hack around our issue though, to be honest :) I don't buy that however, since the reason you have multiple themes is to make your site look different in different areas, and having possibly different theme settings is part of that. Especially now that many heavyweight themes appear with miriads of fun settings.

There seems to be a general agreement here. Let's try this.

the ass-backwards screen detailed in comment #3 as it confuses many new users

@rickvug So remove that (if that is going to help keeping in mind that all other competeting CMSes have this feature OOB). BUT WHY remove the screen detailed in http://drupal.org/files/issues/how-end-user-selects-theme.gif

If this is not removed it is great, and @Damien Tournoud if the above is removed there is not at all any general agreement. If it is kept, thanks.

Since those who code have the actual power I will not argue further and instead watch the fun when Drupal (may be in 8 or 9 or 10) has to get back to this feature OOB.

Its simply ridiculous that INSTEAD of adding a clear concise statement at the header of the theme picker :"You must BOTH enable and make default a theme to make it visible as your site's theme." (or some better wordings) one has to kill a feature. Ideally we should have a theme browser (please see the latest WP) instead of admin users having to plug in something extra or hunt for themes outside the admin area.

Adding help text is not the way to solve a UI problem. People in general don't read it.

@Its not help text - its a statement at the header of theme picker. Statements or wordings are used all over a software, otherwise people will be having empty text boxes, radio buttons, check boxes. People in general have to read this, to know what is doing what.

Removing a feature is also not a way to solve UI problem. Kill the disease, not the patient.

I am still not sure if this http://drupal.org/files/issues/how-end-user-selects-theme.gif is being removed.
If so I am really very frustrated at attempts at making a non-issue an issue.

And kindly can you explain what is the UI problem in this http://drupal.org/files/issues/how-end-user-selects-theme.gif

OOPs, I argued ;)

@kaakuu: whether you name it a help text or a statement, it is text people don't read. You did not read my text above either on why this screen is a problem for all administrators in Drupal 7. And whatever sites you might try to use a separate administration theme in Drupal 6 or 5 for that matter. Users can choose your administration theme as their site theme. Fun, eh?

@Gabor, this issue is getting confusing. Admins being able to choose theme http://drupal.org/node/292253#comment-1249769 and end-users being able to choose theme http://drupal.org/files/issues/how-end-user-selects-theme.gif are 2 completely different UI issues.

Are we keeping http://drupal.org/files/issues/how-end-user-selects-theme.gif ? Yes or No?

Users can choose your administration theme as their site theme. Fun, eh?

Admin themes can be made to be 'seen' only to admins then.
And I do not get your message regarding the fun, Drupal's Garland has been available to both Admins and end-users and during this phase Drupal had the maximum growth. Was that fun or not fun?

And I do not agree to "it is text people don't read." at least in this context. Arguments already made.

I see a lot of arguments for the statu quo here. We should have discussed this at the early stage of Drupal 7 development. There are very good use cases in favor of statu quo.

Instead of removing features, we should start thinking about splitting Drupal in two: the full powerful version Drupal 7 is and a light version.

I am using multiple-enabled theme in my client's sites and I fear that upgrading them To Drupal 7 will be a pain in the ass if we are not careful.

@kaakuu:

@Gabor, this issue is getting confusing. Admins being able to choose theme http://drupal.org/node/292253#comment-1249769 and end-users being able to choose theme http://drupal.org/files/issues/how-end-user-selects-theme.gif are 2 completely different UI issues.

Well, no. The problem this issue is open for is that admin users can select different themes for their end user theme in Drupal 7 out of the box with the admin theme being one of the options.

Are we keeping http://drupal.org/files/issues/how-end-user-selects-theme.gif ? Yes or No?

That is one of the questions of this issue. There are several options to resolve the problem of this screen showing up with the admin theme by default in Drupal 7. The options are detailed in #30 onwards (by those, who cared to read the options and contribute to that). It is not a yes/no question, but a selection from different options to how we resolve the admin WTF on that screen which appears by default in Drupal 7. At least if your question gets Yes as the answer, we still did not resolve our issue, so we need to pick from the other options. One of the ways to solve the issue is answering No to your question. But this issue is not about your question, but an admin WTF/bug for which the answer could lead to a Yes or No answer to your question.

Users can choose your administration theme as their site theme. Fun, eh?

Admin themes can be made to be 'seen' only to admins then.

Yes, this is one of the options I've proposed in #30 yesterday, among other options.

Thanks for the details and the time.

Yes, this is one of the options I've proposed in #30 yesterday, among other options.

Great! Go ahead with that then.
There were suggestions to end it for the end-users to which I reacted.

To sum-up what I comprehend -
The UI for admin-user is so-called problamatic as it has a dumb 'Enable' checkbox and a radiobutton, ref #3 above
The UI for the end-user is NOT problamatic as it is just a question of single selection as in other websites

My suggestion will be (if you insist on that nobody reads any header text) replace the dumb 'Enable' checkbox with an intelligent one. It works like this. As soon as you click Enable an inline smooth popup comes and says
"This is enabled but not yet default blah blah, to make default blah blah". To more force that the admin user reads this, rest of the screen can be made darker simultaneously like lightbox. This solves the UI issue and the thought chains depicted in #3

@Gábor, as you suggested in #30 (D):

(D) Just live with the fact. Only user #1 sees this at all times, other admins can have this permission revoked to be able to select themes (but in the admin role it will be granted automatically).

I would just live with the fact. ;-)

@xmacinfo: as discussed above a few times, unfortunately I've realized since then, that if you'd actually like to use this feature, it is broken for all users (not just admins), since the admin theme will be selectable for all users.

Looks like we've come to a full circle to where we were in #32. Anyone who still needs this explained all over again?

In addition to the suggestion of intelligent "Enable" above http://drupal.org/node/292253#comment-1891466 what I feel in context of #3 above that it is just a lingo problem

For example instead of

Enabled | Default

changing the language to

Available | Enable

0r a slightly more detailed

Select themes that will be available | Enable what will be seen

can solve the problem.

Given that:

(1) the current implementation of user-configurable themes can't possibly cover all use cases (for example it totally breaks if you do have several different themes for different sections of your website)
(2) this feature is not commonly used
(3) there is a good alternative in contrib

I'm still in favor of removing that completely. See #45.

Per-user themes are a bizarre feature that probably less than 2% of Drupal sites use, and there is absolutely no reason to shove it in the face of every new Drupal installation.

From where do this stats come ? Competing CMSes do shove this feature in the face.

I would even argue that there's no reason for core to offer this feature at all. Are there sites on the Internet that offer per-user themes? Of course. Are there many Drupal sites, whose sweet spot is corporate websites, personal/hobby websites, etc? No. I've built dozens of sites and never once used this feature for anything than debugging (and we have other tools for that).

This is a personal argument. I've built sites where this is a must if I have to make personal statement

If you're not replicating Twitter, MySpace, etc. kind of per-user customization website, you do not need this feature. If you are, you're using a bevvy of contributed modules anyway, and adding an extra one for Theme Switcher is not going to kill you.

Wrong! Many community sites are just forum or forum+blog, all core and no extra.And they do offer users choice of skins. So what you say as "adding an extra" is not a good logic.
Incidentally "single-stuff" sites like all blogs, blogger.com and wordpress offers end-users choice of skin and it is the most widely used feature in blogs and net as a whole. Drupal has already this feature - so no point in making it lag behind by making this not OOB.

@webchick, In context to #3 what you made issue of initially, how do you find #55 and #58 above?

@ Gabor

I thought over your question "Users can choose your administration theme as their site theme, fun ?"

I think it is fun indeed and in a good, honest and useful way.
So long over so many years all Drupal themes have been available to Admins and end-users, all of them.
The Seven theme is a nice cool theme - so I will not mind if my end-users use it.
End-users can choose the theme only but NOT the admin functions! - so there is no trouble there.

And I understand that you have explained things over and over again, so I am at fault if the matter is not reaching my brain -

As of now in D7 super admin can choose a theme for his own use and NOT make it available to end users -
for example he can choose Admin theme for his use and keep it unavailable to end-users,
and Issues in #3 are taken care in #55 and #58. So where is the problem ?

Wrong! Many community sites are just forum or forum+blog, all core and no extra.

@kaakuu: I don't know where did you get this idea, but it's not true. You can see that in usage statistics. And if you are making a Drupal site without contrib, then you are missing almost everything about Drupal..

Per-user themes is an absolutely "childish" feature, it just break your site, does not offer anything else.

Already said it twice, but I think we should remove this, for the same reasons webchick gave. If you're running forum sites, you probably want Advanced Forum / drubb installed anyway, which could easily add back the feature (and in a phpbb-clone-y way).

Marking Damien's #45 rtbc.

@webchick If things have shifted completely from #3 and what you say is what is now,
I repeat as far as I have understood
As of now in D7 super admin can choose a theme for his own use and NOT make it available to end users -
for example he can choose Admin theme for his use and keep it unavailable to end-users

"how to deal with the situation of per-user themes selection including the admin theme" has answer in two steps :
1 Admin can make the admin theme not available to end-user / per-user, that is how things are in D6
2 per-user theme selection has no UI problem - http://drupal.org/files/issues/how-end-user-selects-theme.gif

OOT but I want to clear a gross misconception you have on this
"My personal philosophy is that core should be the home of features that 80%+ sites need"
Core also needs to look at present and future. Present - what other comparable CMS ( like WP and not nukes) are doing, what the most common internet activity is doing. Multi user Blogging is the most common net activity, and if Drupal wants to provide that in future it needs to have user skins by default

Misconception 2 is about the 2%. If you ignore this 2% (you need not cramm features, just keep what is there) they will not be happy and they will not recommend D to another 2% who had the potential to recommend it at another 2% and so on. To be lightweight is good, but to be lightweight you have to survive too. Ultimately it is the population that lets you survive. If you dwindle useful features it is your survival viability is affected in the long run. Better to foresee and prevent it :)

Successful CMS not only play according to needs but also create needs and need-standards.
Whether per user theme is +1 in this scenario can be debated. I guess its -1 from you but +1 from me.

Sorry, I did not mean that status change.

Drupal doesn't try to be the same as Wordpress or Joomla out of the box, we've removed a couple of dozen features in Drupal 7 compared to Drupal 6, and only added administrator-facing features in (other than some small improvements to optional core modules). By doing this, we're able to spend core development time on more critical functionality like fields in core (which really isn't possible from contrib).

Marking back to RTBC.

Multiple-enable theme
My personnal experience comes from clients who know only HTML. When I tell them that it's easier to use a single theme for the complete web site they balk! Even if with a single theme we can design a lot of different types of pages or screens, there is nothing easier for me and my clients to offer them sections of their site in a another theme.

Furthermore, when dealing with portable devices, I need to be able to display another enabled theme for these devices. So here again, for a single site we need to keep multiple-enabled sites.

Drupal right now support using a different enabled theme for portable devices, like the iPhone. Do we want to kill this feature too?

By killing to many features we may need to stay stuck with Drupal 6. Please let's not forget about all the portable devices and or special client requirements to have distinct themes for various sections of their sites.

Per-user theme selection
A contrib module would be fine to let users select their theme. It does not need to stay in core.

However, kaakuu have very good use case for keeping this in core.

Unfortunatly, if we keep this into core, how do we hide seven from end-users?

So I think this issue should revolve around this catch22, not ditching features where we have very good use cases.

Personal, anectdotal stats do not overrule observed over-all trends.

Thanks for settings this as RTBC. Did a cross post.

@ Catch - "Drupal doesn't try to be the same as Wordpress or Joomla out of the box,"

Drupal need not be same as WP but Drupal is trying to make UI improvements *like* WP
and trying to gain share of the 'market' *like* WP.

"we've removed a couple of dozen features in Drupal 7 compared to Drupal 6"

Couple of dozens means at least 24! If 24 useful features have been removed it will be a shock to those who want to come from D6 to D7. I bet those are all not useful features and none are as useful as per user theme. The largest and most common usage in net is blogging and all blog or multiblog offers end users choice of skin as a default. Its now web standard. Web standards need to be part of core.

This is a feature which was already there, and did not need much handling, so there is no conflict with "spending core development time on more critical functionality". It is a feature which is there and not a feature which is being asked, so no question of time being spent on it.

And what is the good reason for removing it? What was raised in #3 I have answered - solutions are there. The refactored issue arose because of #3. If #3 has been solved there is no point in keeping the refactored issue.

I did not mean status change again. Whats wrong!

"If 24 useful features have been removed it will be a shock to those who want to come from D6 to D7"

@kaakuu - Trust me, users will want to update to D7. :)

Also, you make a good point about Drupal wanting to improve its UI like WP. Removing this feature allows for a UI improvement.

Damn cross post! Setting back to RTBC.

@Kaakuu, in some cases they've been moved to contrib, in some cases they already exist in contrib in a much better state, in some cases they've been replaced by better things in core, and in others completely removed because they did more harm than good. Not to mention that if plugin manager gets in properly, it'll be much, much easier to install contrib modules for new users anyway.

Resetting status.

@Webchick - Yep, I meant when I want to have a Drupal site offering mu blogging like bloggers that is essential. WPmu is a competeting market here. But even that apart mu blogging sites are offering or starting to offer this : you as the reader webchick see red skin, you log out and see it as blue skin.
Good or bad - time will tell.

"I am trying to understand why."
Do not try hard :) Sometimes things are clear when years go by. Time!
Please go ahead with this issue as the house wants and let us get busy with other issues.
As for myself, I have noted the changes in the patch, so it won't be hard to re-patch and get back what I want in D7 without any contrib, if I decide to go w-out contrib. As for as D8 that is long story, by that time my crystal ball says it will be back again as in D6

So cheers. Moving onto other issues.

@catch - if plugin manager gets in properly, it'll be much, much easier to install contrib modules for new users anyway.

YEP!! 3 cheers for that! That will make things rock and such debates rather out of air.

@webchick
"Maybe this represents an opportunity for you to build and maintain the User Theme module in contrib to really make this into something cool"

He he :D
I am not that powerful :|
I can make you a good cup of tea or coffee but in Drupal scenario I am just an end end user.
Cheers.

@xmacinfo - we have been voted out :)

Great, we do have an agreement for RTBC.

@webchick I did mention the two points again just to clarify things up since there were confusion in the comments. As far as kaakuu comments, he have valid use cases. However, there are already contrib modules to do the same.

@kaakuu XD

Just noticed this. OG does use the code that got removed. But I'm fine with it - group specific themes are not a good idea. Check out Maureen's live theme settings editor - http://s3.amazonaws.com/HSCI_Videos/drupalcon_paris.mov. That would work nicely for group UI customization I think. We also have OG Panels now, spaces/OpenAtrium, and so on.

OMG -> Maureen's live theme settings editor. This is awesome.

Any info on where I can follow up this project?

Seems like best place to discuss Maureen's theme settings editor is at http://paris2009.drupalcon.org/session/real-time-end-user-theme-configur...

"OG does use the code that got removed."

@Moshe - then I am up for a big trouble unless OG can use the contrib code much discussed here.
OG is heavily used as is per group themes by group owners.
OG Panels or Maureen's is just not same or just not as easy as click and select a theme.

Moshe, will OG be able to use contrib code so that in effect things remain same that is, a Group owner chooses a theme, clicks a radio-button and its all done ?
I think I should submit an issue in OG issues ?

The trouble is not just mine, I bet the huge number of users who have been using OG will be in soup if this function is broken.

@kaakuu OG is a contrib module. It will most certainly be update for Drupal 7 and fix this issue in OG at the same time.

Hmmm in this http://drupal.org/node/491214#comment-1858744 Eigentor puts the use of user's theme choice at 20% and not 2%
And apart from OG, which I forgot to mention earlier, Blog Theme uses that core code.

Excerpt from Blog theme "Blog theme allows users to have persistent themes for their blogs based on the theme they choose for their account. When others view thier main blog page, or any node (of specific admin-defined types) created by them, the reader will see the authors theme instead of their own.
Blog theme is part of the Multi-User Blog install profile."

So Blog theme must be also able to use that contrib and make it ready for D7
Seems like I should submit an issue there also?

As it appears, this core code ws depeneded upon by many modules and in a hurry are we forgetting to foresee other issues/complications ?

Many users have already downloaded, tested D7 and I think this feature removal is coming heavily late.

@xmacinfo - Thanks.
So in effect things will remain same for OG? Is not it?
BTW - where is the contrib we have spoken about that does the same thing - any prototype or finished module that I can test for D7 ? If you have the link please post it.

I have a feeling that is shaping up into a lesson that to remain troublefree in life, do not belong to 2% or 20%, but belong to 80% :)

http://drupal.org/project/switchtheme

hi Catch, Thanks.
I meant contrib that can be directly used by OG, Blog Theme etc.
I think I will post issues there for it is their problem how they keep the functions intact.
That way, users who use those modules will also be aware and participate in discussions as in this thread apart from Drupal core or core related people like you there has been hardly any 'user' like me.

BTW, Switch theme has no D7 pledge so far as well as lots of bugs apparently.

Edited to add a small note to myself and if it interests any one. Mods, feel free to del if inappropraite here.
A small note to myself -
What was the real issue here? Gabor has explained and I must understand. It is also "fixed" now so I must move ahead. Still -

If it was a problem with Admin theme being seen by users, Drupal has a way already as in D 6 to show Admin theme to Admin only and not other users.
If it was a problem as stated in #3 there is easy solution as stated in #55 and #58
If it is problem for the end-users or by the end-users, choose-a-theme is the simplest UI for end-users. If certain themes, when chosen by end-users, can break a site's design, they should be disabled from the beginning by the super site admin who in any case should be knowledgeable about what he enables for his site.
If it is a feature that has been needing a lot of attention by coders so that it kills their useful time, this is baseless as there is no significant mass of complaints against this feature per Se from D5 and D6 users.

If it is thought that it is used by 2% or 20%, I will make an average of 11% for argument's sake,
The fact is that 11% of D users amount to approx 21,000 users, not a negligible figure in any design or other consideration. And I will draw your attention to the fact that, why do we design for FF ? Its usage was even less than 11% compared to IE and yet we started to design for it because it was evolving web standard. Similarly letting a registered user of my site choose how he makes look his pages or sees the site, is either already a web standard or evolving so in all standard sites as well as email services and the most omnipotent net activity, blogging.Users using my Drupal site is also a netizen who uses any or some of these standard sites or services and expects this in a site. Even his browser or his desktop lets him choose a skin - it is so common. It can be argued that skin and theme are not the same thing but then theme is the only way to get skin in Drupal so far. If something is so standard it ought to be in core, not somewhere else.

@kaakuu:

Wrong! Many community sites are just forum or forum+blog, all core and no extra.

Uh, since Drupal 7 ships with Garland and its fixed width cousin plus a one column (no sidebars) admin theme called Seven and a bare-bones developer theme called Stark, you don't have much use for any theme switching feature at all in Drupal core. I doubt you'll have use for it with core only, you'll at least need to add a theme (or more to actually have value for your theme switching).

If it was a problem with Admin theme being seen by users, Drupal has a way already as in D 6 to show Admin theme to Admin only and not other users.

Ok, can you please inform us about how did Drupal 6 core solved this issue? I don't know that it solved it, so it would definitely be news to me.

Excerpt from Blog theme "Blog theme allows users to have persistent themes for their blogs based on the theme they choose for their account.

Well, that they were lazy to provide their own administration interface for users, it does not mean that we make them harm to let them make up something for themselves, and not extend the meaning of what otherwise is clearly a *user setting*. There is no underlying code removed which would disallow modules like OG or whatever else to actually switch themes, in fact Drupal core already has a place where it does that for the admin theme and is about to have another one if/once the administration overlay is committed. I'd suspect OG was reusing the system_theme_select_form() form function in another context. The underlying support for multiple themes enabled is not gone, just the UI and its helper functions to present a selection to the user.

@Gabor - Thanks

"you'll at least need to add a theme"

Ya sure. What's the problem in that? Even two or three is fine for me, it breaks the occasional monotony of the users.

"how did Drupal 6 core solved this issue?"

Follow the steps in the attached diagram. This is bound to work. If not I can give a demo url.

"There is no underlying code removed"

Moshe said in #85 above "OG does use the code that got removed."
I based my reaction on that. Otherwise I was peaceful after treating Webchick with coffee :)

@kaakuu
I couldn't believe this so I tested with a fresh D6.13 installation.
* enabled garland and minelli
* garland is admin theme; minelli is default
* user with "switch theme" permission can select one of garland or minelli

Which version did you use?

Drupal 6.13

@stBorchert - You DID NOT follow the steps in the diagram. Those were super easy steps.
Please follow the steps and at least try once more.

I am preparing a demo within five minutes and posting the url.

I'm probably going to regret having this issue in my tracker... Hopefully it's almost run its course. But I know the answer to this: The admin theme in D6 does not have to be enabled. If it's not enabled, the users can't switch to it.

Michelle

Michelle: we went over this above: if it is not enabled, admins cannot configure it either.

@Gabor, @stBorchert - I hope things are clear now. If any problem with name, passwords let me know. After you test OK I will reset those.

Edited - links and passwords of demo removed. If asked I will post again.

@kaakuu: yes, as we discussed above, you cannot configure an enabled a disabled theme. What you did is you disabled Garland and it did not indeed show up in the user selection. The reason it did not show up is not because it was an admin theme, but because it was not enabled. You could have reproduced this with any other theme. This is one of the magic hacks people use when using multiple themes, but that does not make it less of a hack. We strive for better implemented features, and since we do not see this as a widely used feature (as said by multiple people above), it will strive better in contrib (if people do actually use it of course).

"if it is not enabled, admins cannot configure it either."

I did not get it Gabor. In the above diagram and the live demos above I configured Garland's color etc though it is not enabled ( in step 1 of the diagram ) . The changed configs or colors show to The Admin.
Garland was enabled as Admin theme only.

The ordinary auth user cannot see Garland or its changes like changed color, he can choose from the other themes only.

I really cant see the points in this entire issue, and removing a system module setting which has been there for so long in core (people never thought it will be removed one day) indeed needs rethinking logically.

@kaakuu: to manage your admin theme and make any setting, you need to enable it again. When it will show up in the theme listing. Not clear enough?

"This is one of the magic hacks people use when using multiple themes, but that does not make it less of a hack. "

This is hack ? This is just switching on or off one or two standard settings in the system settings. You call that hack ? It does not touch code or anything.

First you said "Ok, can you please inform us about how did Drupal 6 core solved this issue? I don't know that it solved it, so it would definitely be news to me." Now when I do so you say something which is messed up to me. This is the most standard way do things, and the most standard solution to the problem you presented : "it cannot be done"
I do not purchase what you say now in http://drupal.org/node/292253#comment-1895552 after seeing that this can be done. Thats what many of us have been doing.

Regarding your theory on minimal usage, there are many modules still in core with lesser usage. But I will not argue further - I have made details note of those in notes to myself above.

"@kaakuu: to manage your admin theme and make any setting, you need to enable it again. When it will show up in the theme listing. Not clear enough?"

Sorry you are outright confused. You enable it in step 2 ( please see diagram ) once only and thats it.
As The Admin you can always see it in the theme listing and whether enabled or not you can see it and configure its settings by just clicking the 'configure' link.
It will NEVER at any state or phase of Admin action show up in the list of general end users. NEVER!

I have posted diagrams, given live sites' links - I do not know how to make you understand further.
Your problem of letting an Admin theme visible to Admin only and not site's end users is WELL solved.

@Kaakuu, try visiting admin/build/block with and without the theme enabled, and see if you can see a tab for it or not.

So you set up the blocks you want in your admin theme with the site offline and then go disable it. It still works fine as an admin theme and most folks aren't going to be re-configuring it on a regular basis. I'm not arguing for or against taking the per user theme selection out. As long as it's in contrib, I don't care. But the fact is that D6 does let you have an admin theme that is not selectable by normal users and it's working just fine for lots of people. It may not be the method that folks want to continue to use in D7 but calling it a hack is silly.

Michelle

"@Kaakuu, try visiting admin/build/block with and without the theme enabled, and see if you can see a tab for it or not."

@Catch, First of all please follow the steps said. Do not confuse things and make them appear complex.
Garland, in this example, is enabled ONLY as Admin theme in step 2 of the diagram above. It is not enabled elsewhere. So I do not understand why I have to play with "with and without the theme enabled"

Now, even if I make a visit according to your suggestion to admin/build/block I can see tab for Garland. That is what is expected and that is what is happening. Try for yourself as The Admin in the live demo above.

Auth users / end-users to my site cannot visit admin/build/block and they cannot see Garland tab. That is what is expected and that is what is happening. Try for yourself as demo user in the live demo above.

You can do everything in the live site and there is no need of taking the site off or anything. Theme chosen as Admin theme only remains invisible to other users in any state and always.

the admin theme (in D6) can be configured even it is disabled. It was fixed with issues:
#201577: show admin theme on page admin/build/themes/settings
#192779: Don't show disabled themes on blocks settings page

Actually Kaakuu's right there - if you have a theme enabled as an admin theme, but otherwise disabled, it will still appear at admin/build/block. Confirmed this is also the case in HEAD.

In that case. I'd support removing the 'enabled' checkboxes for themes on admin/appearance entirely - since any site which programmatically needs to enable more than one theme can either add them back, or use similar logic to the administration theme to ensure the configure link and block administration is available. The core use case - admin theme different from front end theme, is already supported.

@Catch
What you suggest appears very complex to me and I think we are inviting unnecessary complexities
and unforeseen bugs. Any demo of what you say so one can follow ?

Is there any good reason for killing the way things worked in D 6 at least in this respect?
I answered all the issues raised so far here
There are many modules or codes which are still in core and not used by 80%
If you think of removing the 'enabled' checkboxes that should be another issue.
This issue has changed completely twice already.

And so far there is no reliable contrib or any D7 pledge from the mod you gave link of.

@kaakuu: While disabling the admin theme might still let its blocks and theme specific configuration be adjusted, most systems in Drupal are tailored to work with what is enabled. Not sure how the Drupal 7 code registry works with a disabled admin theme and sure that the update status module will not look for updates for disabled admin themes (which can easily be a security risk if you are not using an admin theme shipped with Drupal core).

@Michelle: See above. Is it not a hack that (seemingly) some subsystems of Drupal are specifically patched to work with but many others are not?

In fact I have been testing Drupal 7 so far that behavior of Drupal 6 is there in Drupal 7 dev version also.
Why kill it at this late stage particularly when things are working well. And no there is no hack here too just default behaviors on setting something on or off.

@gabor - you seem to come with newer defences :)
Does update look for disabled core modules? If so, it should look for disabled themes too.
And in any case one may disable any Admin theme and use another of choice. Or any theme can be disabled and still kept in folders. That is a separate issue completely needing to be addressed in security docs.
And regarding "most systems in Drupal are tailored to work with what is enabled." - Exactly so. It is enabled for the Admin and there is no problem whatsoever in the working of most systems in this case.
"While disabling the admin theme" - No! Admin theme is not disabled. Its enabled for the Admin and made unavailable to other users.
Many patches keeping on happening in the course of a software's developement, D6 is not a hack of D1. Or if it is that is philosophical discussion outside the scope of this thread.

Issues like #3 or issues you raised previously have already got better and proven solutions than killing this feature for the end-user.

@kaakuu: I realize I suggested this grand hack to make the admin theme somewhat configurable even if disabled (yes, I did, shame on me: http://drupal.org/node/192779#comment-661039). I totally regret it (look I did not even remember it works that way).

Whatever is enabled in Drupal is loaded into PHP, checked for updates, translations, etc. Disabled modules are not covered by update_status (unless you install a contrib module for that), neither disabled themes. Disabled themes never get their translations imported, since you never enable them (that's when UI translations are imported in Drupal).

Enabling a theme should not mean it is available to end users. The problem that it was made available to end users was "solved" with some ugly hacks (yes, on my suggestion, shame on me again), while instead we should have solved it in a more sane way. Enabling a module often requires permissions and other configuration too to have end user features available. For themes, the clear solution would have been to have a selection of themes you specifically make available to the end users to choose from. That would cover:

- you trying out themes on the site (while others cannot select them) - but they can still select from the remaining configured themes
- you having a clearly enabled admin theme (which gets update_status coverage, translations imported, etc), but users cannot select it
- you setting up themekey module for site section theming and have a different set of themes for users to choose from all at once

This grand hack of letting the admin theme somewhat work while being disabled is really a very narrow approach to a little part of the bigger problem that when a theme is enabled, it is pushed into the face of users. Letting the admin theme work disabled does not solve the other issues.

Therefore I've opened: #542828: Do not special case disabled admin theme.

Ps: I'm working on implementing #491214: implement the top level Appearance / Choose Theme admin page, and we really need a definition of what enabled means, so therefore the overall thinking on its issues and the attempt to properly solve them finally.

Did you call it hack at that time or did you call it patch :)
The page shows probably you called it patch ;)

I was actually looking at your profile and seeing the thousands of commits you made
and you, webchick are all maintainers of this great D, which we use.
I should not have argued so much as I really cannot change any decision, more than that showing respect should be there. I am sorry.

However, I am done with this. It took my time to set those gifs and the demo.
Whatever is done, the end-result should be registered members should be able to choose the theme of their choice. And despite the 2% or 20% theory here, this is so common or getting so web-standard, I believe it ought to be in core like it was or still is in the D7 dev version at this moment.

PS : Giving 'permission's to Admin theme or making the Admin theme a module with permissions can probably solve the problem. Also I enabled Seven for the non-admin end-user. It looks cool and nice, and I feel no problem in it being shared by everybody. The only problem with Seven is that the name will become irrelevant and rather boring with D 8 and later versions :)

I'd recommend moving this to contrib and that 2% of sites who use it (or contributed modules such as OG) can simply install it if they want this advanced feature.

It would be better if it's still in core, but turned off by default. And what's the point of having the color module enabled by default if there is no way to change colors.

-1 on removing this feature, but +1 on changing the language on the Appearance page to make it clearer. #12's suggestion is the best I've seen: Change "Enabled" to "Selectable by users".

Removing this feature would be a regression, making Drupal less competitive by removing something that other CMSes offer. The simple correction specified here will prevent frustration.

Wanna talk about frustration? I just spent a good chunk of time writing a book section, "To allow users to change the theme they see". I went through the whole process... and then found the control removed from the user page. WTF? Someone forgot to remove the "Select different theme" permission. :-/

The permission was not removed indeed.

I wasn't aware of this bug, and had tgeller create a bug for comment #119. Please see: #559306: Need to remove "Select different theme" permission for a patch to remove the permission and update the text on admin/appearance.

Also: I've added a new feature request for the devel module to add the per-user theme selection capabilities. Please see: #559314: User-specific themes.

The patch was submitted for issue #559306: Need to remove "Select different theme" permission. I've marked this issue back to "fixed."

When removing functionality from core there should be a working contrib alternative. And not something that requires a devel module.

I went through this thread, through http://drupalmodules.com/ and I've used d.o's search function, but I can't find any module that implements this.

@Kasper module with a D7 release already: http://drupal.org/project/themekey

ThemeKey is a great module, but it does not add the feature that was removed from core, as Kasper Souren tells.

However, there is Swiththeme: http://drupalmodules.com/module/switchtheme

And there are other modules to do just that.

Also, you may need to create a function to hide “admin” themes from the list of themes available to users. For example, Seven should be hidden, as well as any other “admin” themes.

see #1046214: Selection of theme for user - Replacement for D6 Core feature that has been removed in D7 Core

ThemeKey team evaluates to fill the gap ...

Here's a replacement for Drupal 7:
#1046214: Selection of theme for user - Replacement for D6 Core feature that has been removed in D7 Core

Read the ThemeKey release notes:
http://drupal.org/node/1047730

Per user themes were very useful when you are developing a theme replacement for a live site and didn't want it to be visible until finished

Hi from the future.

Looks like this issue only removed 50% (the UI) of per-user theme feature, it forgot to remove the storage and logic that checks it and this has been ported back and forth for 4 years now, causing unnecessary work and performance problems.

Time to get rid of it: #2163035: Remove $user->theme and Drupal\user\Theme\UserNegotiator