Problem/Motivation
As stated in #3050389: [META] Remove dependency to Classy from core themes, Classy will be moved to contrib before Drupal 9 and we have to remove dependencies on Classy from all core themes.
Part of this process includes creating theme-specific copies of all Classy libraries to core themes. This ensures Classy can be removed without impacting those themes.
Proposed resolution
- As needed ,copy libraries and assets from Classy to Umami.
- Create new libraries for every copied library, named with the convention "classy.
".
- Override the Classy libraries so they are not loaded by Umami.
- Any Classy libraries-extend: should now be taken care of in Umami.
The end result is no Classy library assets should load, and Umami experience should be unchanged.
Also: add tests that check to see if any of the copied assets from Classy have changed. If they've changed, there should be a failure that provides instructions on moving the altered file out of the /classy subdirectory.
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | 3106600-11.patch | 38 KB | bnjmnm |
| #11 | interdiff_9-11.txt | 2.78 KB | bnjmnm |
| #9 | 3106600-5-copies.patch | 37.94 KB | lauriii |
| #5 | 3106600--5.patch | 62.4 KB | bnjmnm |
| #5 | interdiff__3-5.txt | 2.8 KB | bnjmnm |
Comments
Comment #2
bnjmnmPostponed on #3096203: Create Classy library dependency tests that can be used for all themes, and verify by providing an Umami-specific classy/dropbutton (this is currently built on patch #40)
This also adds tests that check if any Classy-copied file has been changed. When changed, the test will fail and provide instructions to move the changed file out of the classy subdirectory and update the test to reflect that. A fail test has been added that makes a minor change to action-links.css, which means it no longer matches the Classy file and should be moved to another directory.
Comment #3
bnjmnmPatch fixes a typo in the media library extends. It will also need to be rerolled when #3096203: Create Classy library dependency tests that can be used for all themes, and verify by providing an Umami-specific classy/dropbutton lands.
Screenshots attached that verify every asset copied from Classy loads from Umami and not Classy. If other css files sharing the same name are loaded, the filename explains the non-Classy location they come from.
Two notes
Info from Classy's image-widget.css:
ckeditor_stylesheets:key in classy.info.ymlThis has also been added to Umami in that manner, but I'm not sure how to stop it from loading twice.
ckeditor_css_alter()is called in umami.theme beforethe ckeditor stylesheets are added in a different instance of that hook... even when
themeManager->alter()is called second. Quite possible I was doing something wrong, but it's also worth noting that the worst-case on this is one CSS file loading twice, and that will stop when Classy is removed.Comment #4
xjmThe blocker issue is in.
Comment #5
bnjmnmTest was failing due to the wrong namespace, so the screenshots from #3 are still applicable.
This should address the test fail, and I provided another fail patch to show what happens when a change is made to a file copied from Classy.
Comment #7
bnjmnmCleaning up some formatting in the issue summary.
Comment #8
bnjmnmComment #9
lauriiiI regenerated the patch with
git diff -C -Cfor easier manual reviewing.Comment #10
lauriiiReviewed changes manually using patch in #9. Changes in the patch are related to changing paths, tests or library definitions.
I tested Umami manually to make sure there isn't any obvious regressions. I didn't confirm manually that all libraries have been copied since we have tests for that which I have reviewed earlier as part of #3096203: Create Classy library dependency tests that can be used for all themes, and verify by providing an Umami-specific classy/dropbutton .
Nit: how about
$sub_folderinstead of$type?Besides this, I think this is ready for RTBC.
Comment #11
bnjmnmChanged
$typeto$sub_folderper #11Comment #12
longwaveThis looks ready to go.
Comment #13
xjmSo I definitely did not go through and verify all these hashses. ;)
What's the plan for this going forward? Is it to confirm that no one makes changes to the files copied from Classy?
How do we keep people from just updating the hashes instead of understanding that either (a) they should override it and no longer have the Classy version of it in the Classy folders or (b) If they're updating the CSS in the Classy theme under one of the less likely situations where we allow that and knowing that these hashes should be updated as well at that point?
That's what I was looking for, yay!
Comment #14
bnjmnmThe intent is to communicate this via the fail messages:
And I'm always open to improved phrasing if that would help things.
Comment #17
xjmOK, that looks great to me, thanks! Committed and pushed to 9.0.x and cherry-picked to 8.9.x.
Comment #18
xjmRetroactively checked that all the
url()uses in theumami/css/classy/directory have the relative filepaths updated correctly. 25 total calls in the directory, 25 changed in the patch. I also counted that there were the right number of directory-up for each (7 tocore/misc/orcore/modules/; 3 to Umami's own comparable images folder).