Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.The trend seems to be moving towards base themes (i.e. themes referenced as base theme = fusion_core in a subtheme's info file) being left disabled since their increased popularity in D6, which means that the usage statistics for these themes is going to be underreporting their use.
#456088: Sub-themes not notified of security updates for base themes dealt with the security issue, but accurate stats would also be nice.
Comments
Comment #1
dwwYeah, I suggested that stephthegeek open this issue. I think we basically just need update_status to always consider base themes of enabled subthemes enabled, even if they're technically disabled.
In fact, now that I think of it, even if "update status" tells you the base theme is missing an update, I'm not 100% sure that the "update manager" would upgrade it for you.
Stepping back a sec... WTF? Why do we let this happen at all? What's the point of the base theme being "disabled" if all the code is being used, anyway? This just seems totally weird, counter-intuitive, and the source of a lot of special-cases to work-around bugs coming from the can't-decide-if-i'm-enabled-or-disabled identity crisis that base themes have.
Can't we just fix this by saying if a base theme is being used, it should just be enabled?
Feel free to set this back to an update.module issue called something like "Update manager doesn't properly handle disabled base themes" if we must, but I'd like to at least discuss the wider question before adding yet more special-case workarounds.
Thanks,
-Derek
Comment #2
jensimmons CreditAttribution: jensimmons commentedIf you enable a child theme and a base theme while using Skinr 2 — all the skins show up twice. Which stinks. So I've gotten in the habit on all projects of disabling all themes except for the child and the admin theme. On any project running Skinr, this is required.
Just FYI....
Comment #3
stephthegeek CreditAttribution: stephthegeek commentedCan't we just fix this by saying if a base theme is being used, it should just be enabled?
I started out with that line of thinking as well (because we initially had issues with Skinr/Fusion if Fusion Core wasn't actually enabled), but ended up running into countless issues from users who really didn't want to have the base theme enabled, such as:
- end users have perms to switch the theme (like between diff colour schemes), and having the base theme enabled made that show in the list (removed in D7 I know but there will probably be some contrib for it)
- modules like Skinr that have settings/templates/etc per theme end up with repeated sections in their UI for each active theme
- confusion with extra themes enabled with things like theme settings, block configuration
- extra steps required to enable if you have a multi-theme lineage... even when we told people explicitly in docs they need to enable the base theme(s) too, we were always getting issue reports from people who didn't. Apparently it's just not intuitive.
I think there were other reasons people complained about this, but I remember being surprised at the bits of awkwardness that cropped up with multiple themes enabled that are never directly used.
Comment #4
JohnAlbinOn the surface, it would seem like a no-brainer to have base theme "dependencies" be enabled. That's how modules work; if a module has a dependency, the dependency has to be enabled.
Unfortunately, "enabled" themes mean something different. In D6 this means "allow this theme to be selected by a user as their theme preference". While we removed that feature from core in d7, we left the interface in d7 so that multiple themes can be "enabled" while only the "default theme" is used on the site. We left it up to contrib to determine how to use "enabled" themes that aren't the default.
So… just requiring theme dependencies to be enabled is an API change.
To be clear, we did briefly discuss removing core's ability to have enabled themes that weren't the default. But, I believe, that discussion happened after code freeze, so we decided it was too late to implement that.
Comment #5
dwwSo there's basically no getting around the WTF at this point, and this issue needs to return to a (probably major) bug report about making sure Update manager knows to upgrade disabled base themes (and while we're at it, make sure we check for available releases of disabled base themes in a way that causes usage stats to be incremented)?
Comment #6
sunThe larger, fundamental low-level issue is already the topic of #1067408: Themes do not have an installation status and discussed over there.
If I get @dww right, then we need a stop-gap fix for update.module here. Re-classifying accordingly.
Comment #7
JohnAlbinYes, it would be interesting to see how the usage statistics would change after a fix for this. But I think being notified of regular bug fixes of base themes would be mighty, mighty useful.
Comment #8
mgiffordLinking to related D7 issues #1663172: Require Zen base theme if a subtheme is enabled. & #1663142: Require that the base theme be enabled to use a subtheme.
Comment #9
dwwA) I just marked both of the issues in #8 as duplicate with this.
B) I'm not sure the title of this issue was accurate with the underlying bug. It's been a long time since I've thought about or looked at any of this code, but my memory from #456088: Sub-themes not notified of security updates for base themes is that core now checks and reports if a disabled base theme is missing updates. I believe the bug here is that we never added code to the Update Manager itself to install a newer copy for you, so I think the new title is closer to the intention of this issue. The update status report itself *should* look something like this:
http://drupal.org/files/issues/456088-42.basetheme-updates.D7.png
Can someone confirm/deny this?
C) Perhaps the question of usage tracking for disabled base themes should go into a new issue so as not to get lost nor confuse things in here. However, again, I'm not sure if that's actually broken or not.
Comment #10
catchI think #1067408: Themes do not have an installation status is more important here and it'd fix this by default in 8.x..
It'd be good to fix the update module bug in Drupal 7 but I don't think this is major at all - we have existing major bugs in the queue where update doesn't notify you about anything by e-mail ever.
Comment #19
catchThe disabled status no longer exists for themes, everything is either installed or not.