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.
Problem/Motivation
See: #2489460: [Meta] Move module.theme.css files to Classy or Seven
All these patches conflict with each other.
Proposed resolution
Roll all the remaining module -> Seven issues into one patch once they have been tested and RTBC:
- #2539986: Move theme contextual CSS to the Seven theme
- #2539992: Move theme toolbar CSS to the Seven theme
- #2341221: Node preview bar has usability issues, is difficult to use on mobile, not usable without Bartik, and does not align with the Seven style guide and current toolbar designs
- #2566827: move views_ui.admin.theme.css to seven
- #2566831: Remove user.icons.admin library from core CSS
- #2566841: Move theme shortcut CSS to the Seven theme
- #2566855: Load tour CSS in the Seven theme only when the module enabled
- #2489580: Move taxonomy.theme.css to Starterkit Theme and/or Claro
- #2566847: Move theme quickedit CSS to the Seven theme
Remaining tasks
Get all the above issues to RTBC
Postpone all issues
Create voltron patch
User interface changes
None for Classy/Bartik/Seven. Stark is more stark
API changes
None
Data model changes
None
Comments
Comment #2
LewisNymanComment #3
LewisNymanComment #4
LewisNymanComment #5
cilefen CreditAttribution: cilefen commentedVehicle Voltron or Lion Voltron? It matters.
Comment #6
RainbowArrayFor the front-end UI things, we should make sure we do the funky magic that lets those work on the frontend no matter the theme. This was the example you had mentioned LewisNyman.
Comment #7
gints.erglis CreditAttribution: gints.erglis commentedComment #8
lauriiiI understand the positive things that this could give us. How much I would like to see this happen, I just feel like with the given time we it might be a bad idea to make it happen since I don't believe we could make it good enough. People writing their own admin themes (which is small number of people) would benefit out of this most because they can control the supported modules and frontend themes quite easily but giving that responsibility for contrib project seems really tough with the given artifacts. It would be also nice to find a solution that works everywhere the same way, not that every module implements its own way of managing this.
What happens if markup is modified for some reason in the frontend theme? Also in addition for the CSS and JS admin theme should be able to modify the markup, like the other systems implementing this kind of pattern. Now there is too many things to break your stuff. Someone might say there is already ways to break stuff - yes, there is but its somehow predictable and its happening in a sandbox - in the current theme tree. By making this change we would make frontend themes suffer one more unknown; how does admin theme modify my CSS and JS, what markup is required by it to work properly. TBH I believe some theme wouldn't be compatible with each other at all so there should be some way to define which projects are supported and which not to ensure high quality for users.
And how are we supporting contrib module projects by doing that? Lets say I create my own fancy admin menu module and there is multiple different designs for that, how am I supposed to be providing those with the new ideology? By creating multiple admin themes providing the styles or creating new modules for that? Also not many of the admin themes would be theming my contrib, so am I supposed to be able to find admin themes supporting that contrib? What if I use multiple modules and I cant find admin theme supporting them all and they are not compatible with each other?
I don't feel like all the possible use cases how frontend themes can be used has been seriously considered while making these decisions. I also don't think doing this last minute before RC1 is good idea because we cannot get feedback from the theme developers.
I'm really sorry to be against this and also raising my concerns here especially considering all the good things it could bring for us, but I don't feel confident for staying silent.
Comment #9
LewisNymanRaising concerns are great, I'm happy to talk with you about them. The problem we have now is raising them in the issue queue the day before RC. I have to choose between spending my time today addressing these concerns/questions or working on issues that need to be committed today. This feels like strategic blocking of the issue and burnout of the people involved in these issues. I know you pretty well by now Lauri and I don't think this is your intent here.
We've had this discussion open for a year and a half in #2195695: Admin UIs on the front-end are difficult to theme. The only viable solution we have available today is the current one. Yes frontend themes can still shoot themselves in the foot, but this is giving them one less barrel to do so. There is no desire from theme developers to support Drupal's admin functionality in every custom theme they build. Only taking the CSS out of their hands is not as good as taking the markup out of their hands as well, but we can't achieve that without rethinking how we architect the theme system.
If frontend themes do really have a desire to influence the look and feel of these components, they can easily do this with a library override, that doesn't change.
We don't, see the discussion in #2195695: Admin UIs on the front-end are difficult to theme and the comment #13 in particular. In the future admin themes will support a finite number of reusable UI components, and modules would choose the components they want to use the styling from. We can't implement this until we have a real component-based theme system.
Comment #10
Bojhan CreditAttribution: Bojhan as a volunteer commented@laurri You worked on a strategy for addressing this, could you provide an update on this?
Comment #11
RainbowArrayI added a suggestion for a possible solution in #2632584: Add a "public admin" theme subtype so that admin themes can have subthemes for front-end UI components.
Comment #12
andypost