Closed (fixed)
Project:
Drupal core
Version:
11.x-dev
Component:
views.module
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Anonymous (not verified)
Created:
6 Jun 2018 at 21:38 UTC
Updated:
8 Mar 2024 at 10:54 UTC
Jump to comment: Most recent
Comments
Comment #1
Anonymous (not verified) commentedvaplas created an issue. See original summary.
Comment #2
Anonymous (not verified) commentedComment #6
lendudeAs predicted, this got lost along the way :) Tagging for D9 readiness
Comment #7
xjmComment #8
kristen pol"D9 readiness" isn't an "official" tag. Since this is marked for 9.1, I'm not sure a tag is needed. If it is, it should be "Drupal 9 readiness". Leaving off the tag for now.
Comment #15
lendudeThis still being in, is now leading to people opening bugs #3391465: Views CSS class is changed when underscores and dashes are mixed, lets see if we can get rid of this
Comment #17
lendudeSo this just removes the BC layer. I don't see any way to detect that people are using these classes, all we can detect is if we are suppling them with BC classes, so raising a deprecation notice feel weird since it might not be relevant at all.
Would it maybe be sufficient to add a CR with a code snippet that could recreate the BC classes if somebody still needs them?
Something like this seems to do the trick:
Comment #18
smustgrave commentedCould the issue summary be updated with the proposed solution, "Leave two classes as is." doesn't seem correct anymore.
And you're right not sure how to BC a class removal, and not the first ticket I've seen around this. A CR may be the best thing but even then I imagine if someone is using those removed classes they'll notice when something breaks before the CR.
Comment #19
lendudeUpdated the IS with the new proposal on how to address this.
I'll ping somebody to see if we can get some more opinions on how to deal with HTML class removal.
Comment #20
smustgrave commentedWhatever is decided should post here too #2413847: Remove usages of .js class from core
Comment #21
lauriiiCan we move the BC class to Stable 9? That's the standard approach and allows us to get rid of it once we replace Stable 9.
Comment #22
smustgrave commentedThis may be a dumb question but since the classes are dynamic how do you add those to just stable?
Comment #23
lauriiiCouldn't we just move the logic from
template_preprocess_views_viewtostable9_preprocess_views_view?Comment #24
lendudeYeah that should work, just add that snippet in #17 to stable9
Comment #25
lendudeDid what @lauriii suggested. The other case in stable9.theme that seems to have done this didn't get test coverage as far as I can tell, so no test coverage for that for now
Comment #26
smustgrave commentedChange looks good.
So if this the path forward for any other class removals?
Comment #27
catchThis looks good but we need a change record.
Something like 'Views used to duplicate custom classes like
my__classadded in the views UI into an additionalmy--classas a backwards compatibility layer. This backwards compatibility layer has now been moved to the Stable9 theme. If you were relying on these classes, you should either update your CSS to target the correct class, or add Stable9 as a dependency of your theme'Comment #28
catchComment #29
smustgrave commentedCreated a CR from #27.
Made the recommendation to target the correct CSS classes. Do we know how long stable9 will be around? If that should be added to the CR.
Comment #30
quietone commentedI'm triaging RTBC issues. I read the IS and the comments. I didn't find any unanswered questions or other work to do. Although, the proposed resolution is a bit out of date.
Leaving at RTBC.
Comment #33
nod_Committed 3923a9f and pushed to 11.x. Thanks!
Not backporting, so that it'll only be released with D11.