Open klonos opened 4 years ago
Here's what I think we can do in the short term, as a minimum UX fix:
In the long run, I would like us to move to UI proposed in https://github.com/backdrop/backdrop-issues/issues/131#issuecomment-441398733
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.
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).
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).
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:
What we are doing well:
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):