Active
Project:
Claro
Version:
3.0.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
5 Jul 2023 at 14:18 UTC
Updated:
21 Sep 2026 at 15:18 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
gauravvvv commentedFollowed the steps from issue summary but not able to reproduce in 10.1.x.
Comment #3
kiwimind commentedHi @Gauravvvv
Thanks for taking a look.
I've just used simplytest.me to install a clean version of 10.1.0 and you're right, the display is correct.
Interestingly the classes I mentioned in the initial report are present in 10.1.0, however the CSS order is different than what I'm seeing locally, i.e. the button and button--primary classes are taking precedence over ui-widget and ui-button in the cascade.
I'll have a bit more of a dig to see why this might be and report back.
Comment #4
c. s. comfort commented@kiwimind I'm encountering the same issue on Drupal 10.1.1 and 10.1.2. Did you find a resolution?
Oddly, for me, the issue only occurs on some of my paragraphs that use the Media library -- and it appears to be content-type specific. I have two content types with Paragraphs using the Media library that render the button normally, and another two content types where the issue is the same as you presented initially.
On the paragraphs where the button renders correctly, the related classes are handled in the following order of precedence:
On the paragraphs where the button doesn't render correctly, this is the order:
Furthermore, a couple of other observations as I comment here:
I'll have to do some more testing as well...
Comment #5
c. s. comfort commentedI was able to reproduce this on a fresh install of Drupal 10.1.2 and verified that the issue occurs regardless of admin theme (Claro, Seven). I opened a new bug report over on the Paragraphs module, https://www.drupal.org/project/paragraphs/issues/3381201, but for reference here are the steps I took to reproduce:
Note that I'm on PHP 8.1 in a local DDEV environment.
Comment #6
partdigital commentedI was able to reproduce it as well while working on the Access Policy module.
It appears to only happen if there are no actions links on the page in which the link to the modal is being rendered. For example, on the Access Policy module I have two very similar pages (Access rules and Selection rules). Both of which have links to the modal. I’m using the same trait to render the modal in both places. However, in one case the buttons render correctly and in another case it doesn’t. The difference is that on the Access rules page I’ve already rendered some actions links, on the Selection Rules page I haven’t rendered any.
Compare the following screen shots;
Access rules page:
This renders a collection of links in a table as well as the delete link which is an actions link. This renders the modal correctly.
When I modified the Access rules page by removing the Delete link and the Edit permissions links the action links in the modal did not render correctly.
Selection rules page.
This only has a single link that renders the modal. There are no other links on the page. The delete actions link is also not present. This does not render the links properly.
Comment #7
partdigital commentedWhat appears to be happening is the order in which the jQuery UI CSS is being attached is affecting the styling.
In all the examples that worked the jquery ui CSS was being attached first and the Drupal button.css was being attached second.
In the examples that did not work the jQuery UI CSS is being attached last.
I did discover a workaround (at least in my example). All I needed to do was attach
core/drupal.dialogsomewhere on the form. Once I did that everything rendered correctly. Important: I didn't add this to the modal form, I added this to the form where the modal was triggered.Attaching to the form:
In my case I'm using a ajax link so I attached it to that and it also worked as expected.
Comment #8
saschaeggiMaybe this can be fixed in changing the
weightof the JSComment #9
markconroy commentedIn my case, I have an image field on a node (not in a paragraph, just a general node field). When the media library modal opens, the "Insert" button looks fine, but if I use any of the filters and click "apply" (or even click apply to the filters without having changed any of them), then the .ui-widget library seems to get loaded after the claro library, so I get the same issue that is reported here.
Comment #10
dbielke1986 commented@markconroy
Are you using Drupal 10.2.*, because we have the same so since D10.2.0
Comment #11
markconroy commentedYes, this only started when I updated to 10.2 last week. Or at least, we've only noticed it since then.
Comment #12
dbielke1986 commentedGreat, because I am looking for the root of this problem and at the moment I try to analyse which change of drupal core leads to this behavior.
I will link an other issue which shows this problem.
Maybe we can work together to find the reason for this…
Comment #13
dbielke1986 commentedPlease have a look at this issue:
https://www.drupal.org/project/focal_point/issues/3371179#comment-15145534
Comment #14
dbielke1986 commented@markconroy
This could be the root of this error, or what do you think?
https://www.drupal.org/project/drupal/issues/3397785
BR
Comment #15
mark_fullmerComment #17
amanire commentedLike @markconroy in #9, I am also seeing this on the body field of a node field widget (without paragraphs) when the "Apply filters" exposed filter is submitted via AJAX. I am also seeing this when media library is accessed via the Drupal Media button in CKEditor (in both 4 and 5). The change in cascade order of
.ui-widgetfrom/core/themes/claro/css/components/jquery.ui/theme.cssoverriding.button--primaryfrom/core/themes/claro/css/components/button.cssis definitely causing the display issue.This seems related to https://www.drupal.org/project/drupal/issues/3378341. I'm not sure whether I should rewrite this issue title and description without paragraphs and seven or create a new issue entirely.
Comment #19
quietone commentedThe Claro theme was approved for removal in #3576460: [policy, no patch] Deprecate and remove Claro.
This is Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.
The deprecation work is in #3576668: [meta] Tasks to deprecate Claro and the removal work in #3584638: [meta] Tasks to remove the Claro theme.
Comment #20
smustgrave commentedClaro has moved to contrib