Problem/Motivation
As detailed in #3050389: [META] Remove dependency to Classy from core themes, Classy will be moved to contrib befire Drupal 10. Before that, we have to remove dependencies on Classy from all core themes.
Part of this process is creating theme-specific copies of any templates and CSS files that were previously inherited from Classy. There should be an easy way to distinguish these used-to-be-Classy templates/CSS files from ones created specifically for a theme.
Proposed resolution
In the templates & css directory for every core theme subtheming Classy, add a classy directory with a README explaining that:
- It is for templates/css copied from Classy,
- If a template in this directory is altered it should be moved outside the classy directory as it's now theme-specific.
Remaining tasks
User interface changes
API changes
Bartik, Umami, Seven and Claro will no longer extend Classy. We will be copying templates from Classy to these themes meaning that markup and CSS will remain untouched.
All of the themes are internal, so they shouldn't be extended. If a theme is extending one of these themes, and they also extend Classy templates or target Classy libraries with library extend or override, they will have to move their code to target the Bartik, Umami, Seven or Claro templates and libraries.
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #29 | interdiff_27-29.txt | 3.52 KB | meenakshig |
| #29 | 3095713-29.patch | 5.9 KB | meenakshig |
| #27 | interdiff_11-27.txt | 7.86 KB | meenakshig |
| #27 | 3095713-27.patch | 5.9 KB | meenakshig |
| #26 | interdiff_11-26.txt | 5.06 KB | meenakshig |
Comments
Comment #2
bnjmnmThis patch adds a
classydirectory to thetemplatesdirectory of Bartik, Seven, Claro and Umami.Comment #3
bnjmnmComment #4
lauriiis/Classy is removed in Drupal 9/Classy will be removed during Drupal 9
This might give false impression that this is the only way to solve this problem. Maybe we could just say that this change is being made in preparation for Classy to be removed during the Drupal 9 life cycle?
I'm wondering if we should change changed to customized because we might want to copy bug fixes from Classy to these files in future 🤔
Comment #5
bnjmnmAll good points in #4, here's another revision.
Comment #7
bnjmnmComment #8
lauriiiShould we add folders for CSS files as well?
Comment #9
bnjmnmShould we add folders for CSS files as well?Yes, especially since thats an assumption I realize I've been making in some other works in progress. This patch adds them.
Comment #10
lauriiiWhy are these folders in the root, not in the CSS folder?
Comment #11
bnjmnmM I S T A K E ☠︎
Fixed in patch.
Comment #12
lauriiiAwesome! Ship it 🚢
Comment #13
bnjmnmComment #15
bnjmnmUnrelated test failure set this to NW, setting back to RTBC
Comment #16
lauriiiComment #17
lauriiiHmm, not sure if this should be backported to 8.9.x. Moving back just to make sure.
Comment #18
lauriiiComment #19
lauriiiRelated to #17, I'm unsure if we should backport issues decoupling Classy to 8.9.x because this could potentially cause disruption to themes extending Umami, Bartik, Seven or Claro. There should be no problem in making this change given that according to our policies, these themes are internal and shouldn't be extended. However, it seems potentially a bad trade-off to backport these to 8.9.x since the only benefit would be easier backporting of issues. This isn't all that valuable to us given that we've only made a handful of changes to Classy during the whole Drupal 8 life cycle.
Comment #20
xjmI'm leaning toward 9.0.x only based on #19, but I think a bit more info would be helpful:
Thanks!
Comment #21
lauriiiProbably the most concerning downside is that for some themes it could be more difficult to support Drupal 8 and Drupal 9 simultaneously because of the differences in the major versions. Another downside is that it will be more difficult for us to backport issues.
A good middle step would be backporting copying all the templates to Drupal 8.9.x, but keeping the base theme setting as Classy. This means that pre-existing template extends and library overrides and extends should continue to work. At the moment I can't think of any downside in doing this middle step, and it should mitigate both of the concerns on not backporting this.
I was thinking of this earlier. I'm wondering if we should make the CR part of this issue or as part of the follow-ups actually making the changes? Technically this issue is only about adding documentation so that the folder structure remains consistent in all themes. This won't have any effect on end-users.
Comment #22
xjmThanks @lauriii. The BC layer for the 8.9.x backport sounds like a good idea -- let's get an 8.9.x patch as well so that we can review that and the 9.0.x patch together when planning how to commit this.
Regarding the CR, I think we should start one here that describes the initial change (including both the planned change for 9.0.x and the 8.9.x compatibility layer). Then, we can attach the same CR to the followups and add additional information to it as we commit the subsequent changes.
Comment #23
lauriiiI created a stub change record here: https://www.drupal.org/node/3103178. I didn't fill any specific examples yet since we don't know exactly how it will be yet.
I don't think we need a new patch here since this is just adding a bunch of README files. I added a comment to the parent issue to take this into account in the issues that are doing the actual moving templates over #3050389-12: [META] Remove dependency to Classy from core themes. What is important here is that we backport this to 8.9.x.
Comment #24
xjmThe CR looks good. I made a couple small tweaks to the text. And yeah, backporting this to 8.9.x makes sense based on #23 and the fact that it's just the directories (sorry, I hadn't actually read the patch yet before).
Couple small points:
Technically, this sentence ends with a preposition, which we are taught not to do in English classes in American schools. (Nonsense up with which I will not put!)
I checked the Content style guide. It does not mention prepositions and specifies The Chicago Manual of Style, which allows prepositions at the end of a sentence, so this is fine and don't let anyone tell you otherwise. :P
That said, the word "used" is unnecessary, so I would omit it.
As written, this sounds like an alarming BC break. I would say "deprecated" instead of "removed".
In context, it's not clear what "customized" means. I assume it means "differs from the Classy version of the {CSS file, template}", so let's say that instead.
"Classy" should be capitalized here.
That said, based on the previous point, maybe we should rewrite this whole sentence to:
Comment #25
dwwRe: #24.4:
-1 to this. It's a directory named
classy, not the proper noun for the theme, and case sensitive filesystems exist.That said, +1 to your "that said" text, since it avoids the problem entirely. ;)
Otherwise, +1 to everything in #24.
+1 to the CR text. Looks clear to me. Makes me realize I'll have to do some work for this on a site-specific theme I built extending bartik. ;)
+1 to RTBC once #24 is addressed.
Thanks,
-Derek
Comment #26
meenakshig commentedAdded the changes suggested in #24
Comment #27
meenakshig commentedAdded the correct patch and the changes suggested in #24
Comment #28
lauriiiThank you @Meenakshi.g!
Nit 🧐: This line is now over 80 characters per line: https://www.drupal.org/docs/develop/standards/coding-standards#linelength
Comment #29
meenakshig commentedComment #30
lauriiiThank you!
Comment #33
xjmI've committed this to 9.0.x and 8.9.x, as well as attached and published the CR. (We can update it as needed as we do further development). Thanks everyone!
Comment #34
chi commented@xjm, that CR claims that Drupal core themes no longer extend Classy but that's not yet true. Shouldn't we have published it after #3050389: [META] Remove dependency to Classy from core themes?