[UX][DX] Either remove the notion of "disabled" themes, or properly handle them

[klonos]

Note: although I'm using the "Appearance" page as an example here, this is not the only place with the issue. As another example, disabled themes can still be used as base themes, and only their child theme may be left enabled (in the admin UI).

What we are not handling well:

• You can disable the admin theme, and when disabled, it is still being used as the admin theme (UX WTF).
• You can select any disabled theme to be an admin theme 👍 ...you are not being asked to enable it first though; so once the action is performed, the user ends up with a disabled theme as their active admin theme 👎

What we are doing well:

• There is no "disable" action for the default theme. You must select another theme as the default first.
• The action to set a disabled theme as default is "Enable and set as default" 👍

Anyway, here's a screenshot that shows that in D7 (as in Backdrop) you are allowed to select disabled themes as admin themes:

In D8 and D9, there is no notion of disabled themes/modules, so there's no UX WTF (uninstalled themes are not shown as available options in the drop-down select):

[klonos]

Here's what I think we can do in the short term, as a minimum UX fix:

1. Do not show the option to disable a theme, if it is being used as the admin theme. The user would either need to set another (enabled) theme as the admin theme, or have the default theme be used as the admin theme.
2. Do one of the following:
   • Do not list disabled themes in the drop-down that allows to select the admin theme.
   • If a disabled theme is selected as the admin theme, it is also enabled in the process. We could either provide a confirmation dialog to say that this will happen, or simply enable it, and throw a message to say that this was done.

In the long run, I would like us to move to UI proposed in #131 (comment)

[jenlampton]

You can disable the admin theme, and when disabled, it is still being used as the admin theme

I do this on all my sites, Both Drupal 7 and Backdrop. :) In fact, the first thing I do when I install backdrop is disable Seven. I have been wondering why it was enabled, and thinking in the back of my mind that "we should fix that".

Instinctively, I never want my admin theme to be enabled. I wouldn't want it used anywhere other than on admin pages, so I wouldn't want it to show up in the UI where people had the option to select a theme. Those lists of themes usually show only enabled themes as options, so disabling the admin theme keeps it hidden.

None of the recommended solutions account for not wanting the admin theme to appear where you want front-end themes only, which is what I was using disabled / enabled for.

If I'm not right that the only reason for enabled/disabled themes is to make the disabled ones hidden... what does it mean to enable a theme?

I'm really interested in removing the notion of "disabled" themes. I think it would reveal where enabled/disabled themes are used in core (if anywhere) and that might influence our decision on whether it's safe to remove.

I would like us to move to UI proposed in #131 (comment)

I left a comment on that issue too, but that old Drupal 6 UI failed in UX studies. I think the right answer here is to simplify things, and I'm hoping that removing Enabled/Disabled themes might be the ticket.

[stpaultim]

If I'm not right that the only reason for enabled/disabled themes is to make the disabled ones hidden... what does it mean to enable a theme?

I was experimenting with themes today. In specific, this cool new theme - https://backdropcms.org/project/pelerine

This theme creates a config file. For my testing purposes, I wanted to start fresh with default configuration, so I disabled the theme (to delete the config file) and start fresh. I then was able to re-enable the theme with a fresh default config file (only 2 settings in the config file).

I realize this is a fringe case and that there would have been alternatives for me. I am not offering this in support or opposition to this proposed change. I only offer it, because it was useful for me today to be able to disable and re-enable a theme (even if it wasn't really necessary).

[stpaultim]

Another thought: Pelerine is experimenting with a CSS injector type feature that creates a custom css file in the files directory. It might be nice to delete that the file if the theme is disabled OR this MIGHT be a use case for disabling themes (to clean up after them).

backdrop-contrib/pelerine#5