Problem/Motivation
A bug in libraries-override #2451411: Add libraries-override to themes' *.info.yml makes it difficult to override a library or library asset that has already been overridden. You have to know the theme which last overrode a library and then use the full path to the overriding theme asset. This presents a WTF to themers and makes it difficult to reuse theme code. It also makes the sub-theme dependent on the internal file structure of the base theme.
In normal circumstances overriding an already overridden library would be and edge case, but with the introduction of the Stable base theme, a lot of system libraries have already been overridden. This also implies that possible future changes in the asset file structure of Stable could break sub-themes that override libraries already overridden by Stable.
Workaround
The current workaround is explained in #2642122-4: Overriding already overridden libraries-override requires knowledge of previous libraries-overrides and #2642122-18: Overriding already overridden libraries-override requires knowledge of previous libraries-overrides.
Proposed resolution
1. Fix the bug so that the libraries-override declaration should use the same keys as the libraries declaration in the original libraries.yml file.
2. Maintain a BC layer so that themes that have already used the workaround will not break immediately. Remove the BC layer in D10 (#2852314: Remove BC layer for libraries-override that is already overridden)
Remaining tasks
Reviews
Commit
User interface changes
None
API changes
Method signatures of 3 protected methods in LibraryDiscoveryParser
are changed
Data model changes
None.
Comment | File | Size | Author |
---|---|---|---|
#151 | 2642122-151.patch | 23.72 KB | _utsavsharma |
#151 | interdiff_149-151.txt | 1.43 KB | _utsavsharma |
#150 | 149-150-interdiff.txt | 2.73 KB | eleonel |
#150 | 2642122-150.patch | 23.67 KB | eleonel |
#149 | 2642122-149.patch | 23.69 KB | pingers |
Comments
Comment #2
hass CreditAttribution: hass commentedComment #3
star-szrFor now you need to use the full path. See test_theme.info.yml for examples. http://cgit.drupalcode.org/drupal/tree/core/modules/system/tests/themes/...
Comment #4
almaudoh CreditAttribution: almaudoh commented#3: In other words, after stable overrides the
system/base
library, the key is replaced with a drupal-root-relative path to the NEW stable css file, this is the key you should use in overriding.In Stable we have
So your version should be:
For now, the path has to be hard-coded until dynamic path names like '@stable/css/...' are implemented.
Comment #5
hass CreditAttribution: hass commentedThanks for your hints and the examples. This works now, but it is also not really intuitive and inconsistent.
It is also not documented in
For stable I may use the full path, but for other contrib themes this may not work as these could reside in different directories. This means we need
@foo
for dynamic paths asap. It also means that every core theme library change in future will seriously break a lot of contrib themes.This sounds more reliable to me until
@
is supported:Comment #6
almaudoh CreditAttribution: almaudoh commentedOTOH, using streamwrappers is more elegant than using dynamic @ theme names. #1308152: Add stream wrappers to access extension files
Comment #7
hass CreditAttribution: hass commentedDon't you think a stream wrapper is not a bit overkill for referencing a theme?
Comment #8
almaudoh CreditAttribution: almaudoh commentedPerhaps. But consider that there is more than just one use case for streamwrappers and this happens to be one of the stronger ones.
Comment #9
star-szrAnd in many cases you would not have to use the stream wrapper but it does seem like a compelling option to have available! Thanks for that @almaudoh.
Comment #10
rbaprado CreditAttribution: rbaprado as a volunteer commentedNot working for me:
Comment #11
star-szr@rbaprado I tested that .info.yml file, worked fine for me. Here is a more minimal one that also worked for me. I tested with 8.0.x (commit dbf84c49d57156be0a3527f2808caa6dc44aa168) and Standard profile.
Edit: And it should probably be said, make sure you clear caches :)
Comment #13
star-szrDiscussed this with @effulgentsia, @alexpott, @xjm, @joelpittet, @lauriii, @catch and we agreed that this is a bug but is not major.
For now we should create a follow-up issue to document the different ways you can use libraries-override (including the full path way). Then we would update those docs based on the solution that we come up with here.
Comment #14
star-szrOops, tagging for the followup docs issue to be created.
Comment #15
JacineI cannot get this working for the life of me.
Everyone says use stable at the very least for a base theme, so I'm doing that, but that is making this more complex as far as knowing what keys I should be overriding here. And all I want to do here is:
1 - Override one of the 3 CSS files.
2 - Remove the other two.
I have tried everything I can think of, but neither of these work:
It tried all types of variations with the paths, including the full path, not including it, including the preceding slash, not including it. I tried explicitly setting
base theme: stable
in case there was some weirdness around that. Nothing.No matter what, I still get all 3 files from Stable as if I did nothing.
Comment #16
davidhernandezI'm compelled to argue for this being a major. I understand that the bug itself of overriding a library that has already been overridden might not be considered major, but the problem we have is that Stable overrides practically everything. The end result is most people are starting from a point where these are already overridden. That is tantamount to the api being broken.
Comment #17
davidhernandez@Jacine, looking at what Cottser wrote in #11, you have to leave the original library name, but use the full path of the new CSS fie. So contextual lib, with stable css file path.
Comment #18
JacineAh, Drupal TX is brutal.
What David suggested is working (thank you!).
To help others that run into this, this is what worked:
And this is the logic:
Comment #19
hass CreditAttribution: hass commentedI guess we are only waiting for #1308152: Add stream wrappers to access extension files to implement an easy way that always works.
Today it is a pure nightmare if you have a contrib theme in a folder and another theme overrides again. You are completly lost as you have no idea in what folder structure the theme is saved. For overriding core the above may work, but it will also break if you move the theme to /theme/contrib/foo and another one has it in /theme/foo and so on. This is really a serious issue.
Comment #20
davidhernandezWhy would using a stream wrapper be more elegant? Have those been used anywhere else in a yaml file? It seems weird to use it there, versus using the @ token which we use for other things. Twig extends, for example.
Comment #21
almaudoh CreditAttribution: almaudoh commentedI guess I'm seeing this from a programmer's standpoint. Streamwrappers are already part of php and so we wouldn't need to write additional code to parse the @themename tokens.
I'll look into a fix for this bug.
Not yet, because we don't have the streamwrappers in core yet. But IMHO, using a string like
theme://stable/css/contextual/contextual.module.css: false
looks just as nice as using@stable/css/contextual/contextual.module.css: false
. The difference being that the streamwrappers approach would be usable in any context (not just in yaml files).Comment #23
pixelmord CreditAttribution: pixelmord at Wunder for Hubert Burda Media commentedI ran into that issue and noticed that even if I provide the full path to the css file (in stable) like mentioned in #18, the file provided by stable does not get removed. I end up having both files linked/imported the one that stable provides and the one that my theme provides as an override.
To make this work I had to put both the library_override AND a stylesheet_remove in the info.yml file to get the desired behaviour of replacing the css file.
Comment #24
star-szr@pixelmord can you please provide the YAML you used? Otherwise we may not be able to help or reproduce.
Comment #25
pixelmord CreditAttribution: pixelmord at Wunder for Hubert Burda Media commented@Cottser regarding #24:
I use core 8.2.4
OK so the issue occurs with this yml ( The theme is currently sub-theme of Seven, which itself is a sub-theme of Stable):
If I configure like above shown, I still have both stylesheets linked:
If I add the stylesheet that I wanted to override to te stylesheets_remove array, everything works as intended:
Comment #26
davidhernandezTo be clear, you did a cache rebuild and all that fun stuff?
Comment #27
pixelmord CreditAttribution: pixelmord at Wunder for Hubert Burda Media commentedSure I cleared the cache.
I also tried that override again with another css file that I specifically created for testing, so I can be sure that the file shown in the above image was not attached someplace else. Same issue, after specifying the override in the info.yml file I get both files attached the one from stable and the test.css.
Just now I checked and tried to just remove the file by setting it to false, that did not work either, the node.module.css is still linked.
That is what I specified for that test:
It might have to do with the double inheritance of: Stable > Seven > Thunder Admin
I will fire up my debugger and see what I can find out..
Comment #28
davidhernandezIt shouldn't because Seven uses Classy, not Stable directly. Stable > Classy > Seven. So any theme using Classy would have the same problem. That would be easy to test.
Comment #29
pixelmord CreditAttribution: pixelmord at Wunder for Thunder commentedYeah @David found that out as well.
And I did some step through debugging and found out that the methods in Drupal\Core\Asset\LibraryDiscoveryParser work totally fine!
The only thing that does not work totally fine is my brain, because after some serious thinking what else could be a reason for this happening is that stable overrides TWO libraries that attach the file and my theme just did override one of those libraries, because I just did not think of that!!
What makes that worse is the fact that for the node form both those libraries are required for some reason.
So the following YML works and successfully removes the file:
So no additional bug here other than what was originally reported, sorry.
However it might be interesting to find out why stable/core-node-module has two libraries that require the same css file and both get attached to the node form but that is an issue for another day...
Comment #30
almaudoh CreditAttribution: almaudoh commentedLet me work on this over the weekend. Seeing as streamwrappers are not remotely on the horizon, let's see if we can make
@theme
token work.Comment #31
almaudoh CreditAttribution: almaudoh commentedWe start with a test that should fail...
Comment #33
almaudoh CreditAttribution: almaudoh commentedMore strict YAML parser in testbots. Still expecting 1 test fail only.
Comment #34
almaudoh CreditAttribution: almaudoh commentedEmbarrassing when fail patches refuse to fail :(. Seems like the @ token is causing problems with the PECL Yaml parser on the testbot. I'm using Symfony Yaml parser on my local machine, so I'll remove the @ token just to confirm the patch fails.
Comment #35
almaudoh CreditAttribution: almaudoh commentedA more careful look at the test result shows that the test actually fails, it's just that DrupalCI does not report it. https://dispatcher.drupalci.org/job/default/281509/consoleFull
So here is a full patch with the fix.
This patch does the following:
1. Allows the use of the original overridden asset path when overriding (no matter how many parent themes have already overridden already). So for the example in #4, the override can now be written as below and will work irrespective of whether base themes have overridden them already or not.
2. In order to maintain BC with the current behavior (which isn't very themer-friendly), it will also work if the previous overriding path is used. It will also work if using the @theme token to represent the previous overriding theme path. This approach is not necessary anymore and is not recommended.
3. If a base theme had removed an asset using
path/to/original/asset.css: false
, the sub-theme can reinstate it or still override that withpath/to/original/asset.css: path/to/new/asset.css
. This is currently not possible in HEAD, (except you uselibrary-extends
).The entry on the left-hand side of the
:
is always relative to the original library location while the one on the right-hand side is always relative to the sub-theme's location. (Well that might be another WTF, but how to fix that).Comment #36
almaudoh CreditAttribution: almaudoh commentedComment #37
davidhernandezSo if I'm reading #1 right comment #35, the patch solves the original bug? Why do we need the dynamic path token?
Also...almaudoh to the rescue!
Comment #38
almaudoh CreditAttribution: almaudoh commentedWe actually don't need that anymore, so I can remove it in the next patch.
What do you think about maintaining the current behavior? Should that be removed now or deprecated to remove later? I looks like a lot of .info.yml files have already been written based on that behavior.
Always happy to contribute when I can :)
Comment #39
davidhernandezI think we'll need to leave the existing behavior for backwards compatibility. A lot of people are already doing it as a work around, so we don't want to break their themes.
Comment #40
almaudoh CreditAttribution: almaudoh commentedOk. I have removed the dynamic path tokens and retained the existing behavior for BC.
Comment #41
hass CreditAttribution: hass commentedRemoving the @themename is incorrect!
The problem is that themes can be saved in every directory e.g. sites/all/themes/foo or sites/all/themes/contrib/foo or /themes/foo or sites/all/themes/basetheme/foo and the directory is not predictable.
Therefore we need this "@foo" token or the path may not overridden. Theme developer do not know where all the thousands of their users install the theme.
Comment #42
davidhernandezThe path doesn't have to do with where the library is located. The path is defined by the original library and is internal to the theme or module where it came from. That path is always the same.
If you want to override the system/base library, you always use "css/components/autocomplete-loading.module.css", no matter where your theme is. This path comes from the system module, not your theme.
Comment #43
hass CreditAttribution: hass commentedI guess #4 is the root cause of my confusion... if the /core/ folders are not added all should be good I guess.
But "stylesheets-remove" will not work without the @theme_name. Consistency wise not so perfect.
Comment #44
almaudoh CreditAttribution: almaudoh commented#4 was just a work-around for the bug. After this patch, you no longer need to use that approach. Just what @davidhernandez says in #42 will work.
The
@theme_name
token for "stylesheets-remove" is not affected by this patch and still works as before. Also, I believe "stylesheets-remove" was deprecated in D8 for "libraries-override" and "libraries-extend". So it shouldn't be used for new themes.Comment #46
almaudoh CreditAttribution: almaudoh commentedThis patch still needs manual test and review so it can go into 8.3.0. RTBC anyone?
Comment #47
kostyashupenkoI've tested last patch (#40) on 8.3.x branch at bartik/seven themes and it works for me
Comment #48
alexpottThis @todo should have an issue filed against it for 9.x and the issue should be linked here.
The value assignment in the
if
is unnecessarily tricksy to read cause of the negating and additional brackets. Also the comment inside the if code by more descriptive.I think this can return FALSE no?
I think this can be FALSE - no?
Comment #49
almaudoh CreditAttribution: almaudoh commentedThanks for the review @alexpott
1. Opened #2852314: Remove BC layer for libraries-override that is already overridden. Also added link in @todo
2. Fixed
3. Fixed
4. Fixed
5. Added test coverage
6. #2852317: Document the different ways 'libraries-override' can be used (including the full path way)
7. There was already a CR from the parent issue https://www.drupal.org/node/2497313 which documented the correct way of doing it. The buggy behavior or workarounds for it were not really documented anywhere. I don't think we need a CR either.
Hope it's okay to re-RTBC this since the only real code change is #48.2 which is really minor.
Comment #50
almaudoh CreditAttribution: almaudoh commentedSmall CS indentation adjustment...
Comment #51
alexpott@almaudoh given the added test in #49 convention would mean that setting to needs review would be better than re-rtbcing yourself.
Reading the test made we wonder if we have test coverage of what happens is a base theme sets something to false but the sub theme has an override?
Also this is likely to miss the window for getting in to 8.3.0 (because there is only 5 minutes to go). The current patch is making changes to protected methods that we wouldn't make in a bug fix release like 8.3.1. In order to get this in to 8.3.x we'd need to rework the fix with a tighter focus on BC in mind (if possible). So moving to 8.4.x.
Comment #52
alexpottThe issue summary could also to with an update to detail exactly what the issue is - much is implied rather than explained. Plus the proposed resolution needs fleshing out.
Comment #53
almaudoh CreditAttribution: almaudoh commentedUpdated the issue summary.
Sorry, forgot about the test.
@alexpott, what exactly do we need to do to get this in 8.3.x? I'm considering that more themes will end up having to use the workaround for the next 6months until 8.4.x?
Comment #54
almaudoh CreditAttribution: almaudoh commentedComment #55
almaudoh CreditAttribution: almaudoh commentedComment #56
gpap CreditAttribution: gpap commented[deleted]
Comment #57
DuneBLThe following (without the patch) doesn't work from a subthemed bootstrap theme (8.4):
Top of prog_tpm.info.yml
override in prog_tpm.info.yml
cache cleared...
Comment #58
davidhernandezBootstrap doesn't use Stable. Unless Bootstrap overrides one, you'll be getting libraries and assets directly from core.
Comment #59
DuneBL@davidhernandez
My bad... I was looking in an admin page!!!
I would like to override a toolbar stylesheet for my theme and my admin theme...
For the theme (not admin), I can add the libraries-override in info.yml, but for the admin theme, should I create a subtheme and add the same libraries-override in the subtheme.info.yml just for that?
If yes, how could I make it point to the same overrided css file used in my site theme or, maybe, I must duplicate it? (or is there any other more clever solution?)
Comment #60
Dennis Cohn CreditAttribution: Dennis Cohn at iO commentedI can confirm #56:
Patch #50 does not fix this bug on 8.3.2, at least for Seven sub themes.
Still got issues with these files in my subtheme of seven. I need to include these files below in my own subtheme.info.yml to make the status report page to look nice.
Comment #63
markhalliwellAnd that title...
Comment #64
kostyashupenkoreroll
Comment #65
jofitz CreditAttribution: jofitz at ComputerMinds commentedRemove "Needs Reroll" tag.
Comment #66
almaudoh CreditAttribution: almaudoh commentedCan we have more people do further manual testing on the patch. I've not been able to replicate the issues mentioned in #56, #57 and #60.
Comment #67
Anonymous (not verified) CreditAttribution: Anonymous commented#66: Steps to reproduce:
This is due to the fact that
$all_libraries_overrides = ['seven', 'stable']
. As a result, override occurs from the child theme to the base theme, although the opposite is necessary.At first I tried to reverse
$base_themes
in the\Drupal\Core\Theme\ThemeInitialization\getActiveThemeByName()
, but it did more harm than good 🤔Comment #69
Anonymous (not verified) CreditAttribution: Anonymous commented#68: Opps, we can not reverse list inside
applyLibrariesOverride()
, because it can get the right order list. Let's do it ingetActiveTheme()
.Comment #70
Anonymous (not verified) CreditAttribution: Anonymous commented#69 Green! Now with test to #69 change.
70-test-only.patch = 70.patch without
ThemeInitialization
fix.Comment #72
almaudoh CreditAttribution: almaudoh commentedThanks, @vaplas. Patch #70 now needs manual testing from others...
Comment #73
Anonymous (not verified) CreditAttribution: Anonymous commented@almaudoh, thank you for quick feedback!
Just clarify. #64 passes, only because it does not check the cases when the theme is based on at least two themes with
libraries-override
same files.Good example: admin themes based on Seven (most common case). All these themes get defects every time when we add rules to
libraries-override
section of the Seven (or change these files). Here's how the status page looks for Adminimal theme:Of course, this is not an absolute collapse, but bit unpleasant.
Comment #74
alexpottI'm wondering about the BC implications of this change. Might something rely on the current order? That said, this is obviously the correct way to process overrides and maybe we can consider the current behaviour just very buggy and themes are likely to have had to come up with ways to address this themselves.
Comment #75
alexpottI think we should trigger a silenced deprecation here because this only happens for BC - right?
That'll mean that tests that invoke this code will need to be legacy tests and expect the deprecation message.
Comment #76
volkerk CreditAttribution: volkerk commentedThis patch fixes three different problems for the thunder_admin theme:
For example stable and seven both provide an override for misc/vertical-tabs.css in core/drupal.vertical-tabs. Unfortunately the override in stable changes the key for said asset to an absolute path '/core/themes/stable/css/core/vertical-tabs.css', therefore the override in seven does nothing
Without patch the order in which library overrides are applied is broken. For the thunder_admin theme we had (seven > classy > stable > thunder_admin) after applying the patch it is as expected (stable > classy > seven > thunder_admin).
If you try to override assets in a library with multiple assets the order of these is not respected, overrides are simply added at the bottom. Since the order of css assets in seven/global-styling is important, it is impossible to override single assets.
Comment #77
alexpottI'm pretty sure the #76.1 and .2 are tested by the patch but does .3 have test coverage?
Also I think this is a major bug because without fixing it extending from other themes doing overrides is impossible.
Comment #78
volkerk CreditAttribution: volkerk commented.
Comment #80
volkerk CreditAttribution: volkerk commented.
Comment #81
volkerk CreditAttribution: volkerk commentedAdd deprecation warning, align tests and fix seven,
add test for #76.3.
Should be green after https://www.drupal.org/i/2973791.
Comment #83
volkerk CreditAttribution: volkerk commentedComment #85
alexpottTestbot wobble.
Comment #87
almaudoh CreditAttribution: almaudoh commentedRerolled patch for 8.7.x
Comment #89
acbramley CreditAttribution: acbramley at PreviousNext commentedConfirmed patch in #81 fixes issues with removing hidden.module.css via:
Prior to the patch I needed:
Comment #90
alexpott@volkerk pointed out to me that this is related to #3019482: ActiveTheme::getBaseThemes() can return the wrong themes - that issue fixes the list of base themes to be correct for an active theme. Atm it is not always which makes this even harder.
Comment #91
almaudoh CreditAttribution: almaudoh commentedI don't understand the test fails yet, so a reroll first. Maybe #3019482: ActiveTheme::getBaseThemes() can return the wrong themes may solve it.
Comment #92
almaudoh CreditAttribution: almaudoh commentedComment #94
almaudoh CreditAttribution: almaudoh commentedWe'll wait for #3019482: ActiveTheme::getBaseThemes() can return the wrong themes.
Comment #95
BerdirLooks like that other issue was close as duplicate of yet another issue which has actually been fixed now.
Comment #96
BerdirComment #97
almaudoh CreditAttribution: almaudoh commentedRe-uploading patch in #91. Let's see if it passes now.
Comment #98
almaudoh CreditAttribution: almaudoh commentedActual patch now...
Comment #101
almaudoh CreditAttribution: almaudoh commentedLet me take this on again...
Comment #102
almaudoh CreditAttribution: almaudoh commentedRe-roll first
Comment #104
almaudoh CreditAttribution: almaudoh commentedA key component of patch #81 was missed out in subsequent re-rolls (notice the change in file size). This has been reinstated.
Comment #105
cedeweyThis latest patch works as expected. Thanks!
Here's a working example - https://git.drupalcode.org/project/encontrarlo/commit/64bbcf8
Comment #106
Wim Leers#105 did manual testing.
The patch no longer applies though — this needs a reroll!
Comment #107
sokru CreditAttribution: sokru as a volunteer commentedJust a reroll
Comment #108
almaudoh CreditAttribution: almaudoh commentedFailures in #107 are due to deprecation notices.
Comment #109
AjitS@sokru - It is recommended that you remove the "Needs reroll" tag after you upload the rerolled version.
Comment #111
rromore CreditAttribution: rromore at Webspec commentedRerolling for 8.9.x.
Comment #112
kostyashupenkoComment #114
dpiComment #115
Neslee Canil PintoComment #117
MaxPahDeleted
Comment #118
MaxPahThe patch in comment #115 broke my site with this error (Tested on Drupal 8.9.0) :
I changed only the the 2 call to method $this->setOverrideValue to get this working.
Comment #120
MaxPahPatch has been recreated to reduce test errors made by my old patch.
Comment #122
AaronMcHaleDevelopment should now be done against 9.1.
Comment #123
ravi.shankar CreditAttribution: ravi.shankar at OpenSense Labs commentedHere I have added reroll of patch #120 for Drupal 9.1.x.
Comment #125
bradallenfisher CreditAttribution: bradallenfisher commentedCan someone help me... i'm trying to unset/override /core/modules/layout_builder/layouts/threecol_section/threecol_section.css
I have tried many variations of
what am i missing/doing wrong?
Comment #126
Wongjn CreditAttribution: Wongjn as a volunteer commentedYou are attempting to override the CSS with the incorrect library key and also the incorrect CSS group @bradallenfisher:
Try this:
Also as per this thread, one only needs to use the absolute path for the CSS file if it is overridden already. This is not the case as it seems from the initial code snippet, so one can use the same path as its definition in its corresponding
layout_builder.libraries.yml
.Comment #127
bradallenfisher CreditAttribution: bradallenfisher commentedThanks @wongjn,
I guess im just confused by the docs. The example to override css from the contextual links module
uses a key pattern like
contextual/drupal.contextual-links:
.How did/do you know that you are supposed to use the key:
layout_builder/threecol_section:
?Comment #128
davidhernandez@bradallenfisher you have to find the original library definition. This isn't something to guess. The first part of the key is the name of the module or theme where the library resides and the second is the library name. If you look in the layout builder module's own library file you should see the libraries it declares.
Comment #129
bradallenfisher CreditAttribution: bradallenfisher commented@davidhernandez thanks man i have it all sorted now. :)
Comment #132
jcisio CreditAttribution: jcisio as a volunteer and at Axess Open Web Services commentedPatch for 9.3.x and applies on 9.2.x.
Comment #133
Sakthivel M CreditAttribution: Sakthivel M at QED42 for Drupal India Association commentedComment #134
acbramley CreditAttribution: acbramley at PreviousNext commentedFixing custom command failures in #132
Comment #135
acbramley CreditAttribution: acbramley at PreviousNext commentedIt's been a long week....
Comment #137
acbramley CreditAttribution: acbramley at PreviousNext commentedComment #139
acbramley CreditAttribution: acbramley at PreviousNext commentedSome of those failures seem to indicate maybe this isn't working as intended? In any case this will fix the
js.module.css
failures.Comment #141
neclimdulOh wow, this seems really bad. Seems like this makes the overrides in a theme an interface that technically can't ever change because it could break subthemes... Yikes.
Also yeah, the experience is frustrating :)
So there are some problems with the last patch that should be fixed with this patch.
Additionally I went ahead and renamed the "legacy subtheme" to match the other legacy themes.
There should be two failures.
Comment #142
grace_karuna....
Comment #144
altrugon CreditAttribution: altrugon at Affinity Bridge commentedI was able to override libraries previously overridden by Olivero theme like this:
mytheme2022.info.yml
As you can see the
system/base
part is the previously overridden part and it required to add the full path to the Olivero's CSS file in order for the override to work.I hope this helps others, and thank you so much for the hard work.
Comment #145
noopal CreditAttribution: noopal commentedHow do I know whether it is component, theme, layout etc.
I am trying to override autocomplete JS file set by search_api_autocomplete
Thanks
Comment #146
nod_maybe with
/modules/contrib/search_api_autocomplete/js/search_api_autocomplete.js
? (note the "/" at the start)Comment #149
pingers CreditAttribution: pingers at University of Adelaide commentedRe-rolling for 9.5.x... which I know needs to be 10.x, but we need 9.5.x.
Comment #150
eleonelRe-rolling patch for 10.1.x
Comment #151
_utsavsharma CreditAttribution: _utsavsharma at OpenSense Labs for DrupalFit commentedTried to fix CCF for #149.
Please review.
Comment #152
FiNeX CreditAttribution: FiNeX as a volunteer commentedHi, patch #151 also works fine on Drupal 10. Thank you very much!