After creating a subtheme (AT Subtheme), it is possible to disable the parent theme (AdaptiveTheme). This seems like an issue as a subtheme should require the parent to be active and should behave like a dependent module. My main issue with allowing base themes to be disabled while its subthemes are enabled is that when a new update comes out, it is extremely difficult to find out which subthemes would be affected by the upgrade or if a sub-theme even requires an update at all - especially while using Drush.

This is not strickly and AT issue as other themes allow this behaviour but I figured I'd start somewhere.


mgifford’s picture

As we've talked about it, this totally makes sense to me. Subthemes should be acting like modules where there is a required dependency.

Really not clear how to track down security upgrades if the base theme isn't enabled.

Jeff Burnz’s picture

Its not a contrib theme issue at all, this is Drupal core behavior and there is little to nothing I can do about it.

It may well be tied in with how admin themes work since they can work while disabled also, also could be partially a performance issue (maybe) because if you look at the various functions that find base themes / child themes they never check if they are enabled or not and these just happen to be places where you really want maximum speed and no extraneous checks.

Granted AT does its own checks for various base theme / child themes (mostly looking for plugins) and it does not check the status of those themes - I go along with what core allows otherwise I would break Drupal.

I have a rule of thumb for "upgrading" themes and its quite different from modules, i.e. if its working leave it alone, unless its a security issue OR the new version has something you really really want.

mgifford’s picture

Title: Require base theme if a subtheme is enabled. » Require that the base theme be enabled to use a subtheme
Project: AdaptiveTheme » Drupal core
Version: 7.x-3.x-dev » 8.x-dev
Component: Theme Settings » theme system
Category: support » bug
Issue tags: +security, +subtheme

Thanks Jeff. Moving this to core as a bug.

It might have some minor performance implications, but modules do it all the time, so not sure why the same mechanisms aren't involved.

Seems to be a potential security issue. If there is a security issue in the base Zen or AdaptiveTheme, how would Drupal know if it is disabled (and the sub-theme is just latching onto it for the files it needs).

justafish’s picture

My only concern with this is that forcing the theme to be enabled will show it up in places I don't want - for example it will get it's own tab on the block administration screen. Permissions don't currently allow one to grant the configuration of blocks per theme.

Jeff Burnz’s picture

Drupal probably needs special handling just for base themes, so they enable but do not show up. Frankly I've always wanted to use the hidden flag you can set in the info file, but it causes issues with updates and Drush (although that might no longer be an issue, its been a while).

mgifford’s picture

mgifford’s picture


dww’s picture

sun’s picture

Category: bug » task
Status: Closed (duplicate) » Active
Issue tags: +Framework Initiative

Let me re-open this issue, in order to do what the issue title suggests, making it required to have base themes enabled.

That is, as a preparation for #1067408: Themes do not have an installation status, and because it's a rather atomic subset of affected functionality.

We're going to do the same for admin themes: #542828: Do not special case disabled admin theme

dww’s picture

The reason I marked this duplicate is that I already made exactly this proposal at #990610-1: Actively used but disabled base themes are not offered for upgrades by the Update manager and it was effectively shot-down by the various big-wigs of the Drupal theme world. But, if you want to try again, I won't stop you. ;)

sun’s picture

Status: Active » Closed (duplicate)
Issue tags: +API clean-up

Oh, yeah. I will. :) My list of epic problems that this insanity is causing is growing bigger and bigger.

However, in attempting to provide a patch here, I immediately ran into scope-creep.

So I'm going to revert the status to duplicate again - but this time, duplicate of:
#1067408: Themes do not have an installation status

dww’s picture

Sounds good, thanks! FWIW, I totally support you on this. I hope you can win this debate.


mducharme’s picture

Great to see such a quick response! I'll be lurking on the duplicate issue to at least help with testing, specifically with multi-site configurations and Drush.