Objective

  1. Rethink what disabled themes are good for today and how we can/want to resolve their use-cases, since the parent issue destroyed all previous use-cases for disabled themes... for example:

    1. Not exposing (disabled) base themes in theme selection controls
    2. Not exposing the (disabled) admin theme as a theme
    3. ...

Notes

  1. Disabled modules were removed, because they involved data integrity problems — primarily because they have a database table schema, and in general, because they are storing data that may integrate with other modules. Horizontal extensibility.

  2. Disabled themes do not share these aspects — at least not in any way that is problematic. They do not have an own database schema/storage, and they only support vertical extensibility/inheritance via parent/base themes, whereas parent theme(s) cannot be disabled if there are sub themes that depend on them.

  3. Removing the concept of disabled themes does not seem to be required in any way. At least not for the reasons for why we removed support for disabled modules.

    That doesn't mean that the concept of disabled themes is right though.

Comments

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented
Issue summary: View changes
RainbowArray’s picture

RainbowArray
she/her
Primary language English
Location Twin Cities, Minnesota
CreditAttribution: RainbowArray commented

My most common use case for disabling themes is a temporary one. If I've made a change to a theme, but it's not showing up, and I've already cleared cache, then disabling a theme and re-enabling it sometimes does the trick. My guess is that the reason this works is because it has an impact on the registry. While, yes, you can refresh the theme registry with drush, not all people who interact with themes in Drupal use drush.

I'd guess the other use case for disabling themes is when a site allows a user to choose their own theme when multiple themes are enabled. If there are other themes that are in development, but you don't want users to select them, then leave them disabled? I don't think I've ever done that, but maybe others have?

Those are the things I can think of right now for disabled themes.

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott commented
Status: Active » Postponed

Afaik there is no theme selector in core. If people need to limit a theme selector provided by a module then this should be in that form fields configuration - maintaining a tri state theme extension system just for this use case is not worth it. Especially considering the complexity of maintaining theme configuration across multiple deployments (dev, staging, live). The current patch on #2232605: Themes cannot be uninstalled completely replaces the disabled state with uninstallation.

star-szr’s picture

star-szr
he/him
Primary language English
CreditAttribution: star-szr at Northern Commerce commented
Status: Postponed » Closed (works as designed)

Agreed with @alexpott, I think the answer is we don't support disabled themes in D8. They're either installed or not. I can understand that strictly speaking it's not necessary to remove the concept of disabling themes, but…

1) It's consistent with modules which seems like a good thing.
2) The use cases for supporting disabled themes don't sound particularly compelling.
3) Dual state is less complex :)