Why do I see dialog.css in my theme?

Created on 6 September 2022, almost 2 years ago
Updated 15 September 2023, 10 months ago

Problem/Motivation

Im use links to modal, as <a href="/reviews" data-dialog-type="modal" class="use-ajax". Somehow I see connected:

<link rel="stylesheet" media="all" href="/core/themes/claro/css/components/dialog.css">
<link rel="stylesheet" media="all" href="/themes/contrib/gin/dist/css/components/dialog.css">

and ui-dialog stylized by gin...

https://i.imgur.com/c1nP8XF.jpg

Steps to reproduce

Set custom theme generated from bootstrap_sass as default and gin as admin theme.
Add <a href="/reviews" data-dialog-type="modal" class="use-ajax" to block/node.
Click on link.

How to delete it's styles?

πŸ› Bug report
Status

Closed: works as designed

Version

1.0

Component

User interface

Created by

πŸ‡·πŸ‡ΊRussia VVS Russia

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡§πŸ‡ͺBelgium andreasderijcke Antwerpen / Gent

    I confirm this can still happen. It seems indeed cache related.

    My case, in a nutshell: with (all) caches enabled on a frontend theme that does not unset Gin libraries.

    1. As a user that has the toolbar access, view a page in frontend theme with something on it that triggers dialog (on click, for example). Dialog looks fine, upon inspection you can see Gin css is applied.
    2. View the same page as anonymous, trigger the dialog. Dialog theming should be broken. Upon inspection you can see the Gin css for the modal is used and variables are missing.

    From my perspective, even in 1, the Gin modal css should not be loaded, as it means that this user will see the dialog differently than intended by the frontend theme. Is there any reason in particular why it is?

    I've fixed the problem by excluding the dialog css as in comment 3.

    I hear from colleagues that they opted for the workaround as shown in πŸ› Library information alter should not be context-aware Closed: outdated , when it was OK to have the Gin theme mix into the frontend, but that feels wrong to me.

  • Status changed to Closed: works as designed 10 months ago
  • πŸ‡¨πŸ‡­Switzerland saschaeggi Zurich

    Closing this again as the library is being used in a lot of distros which don't style dialogs in the frontend and want to have the same styling as in the backend.

    We can argue about opt-in vs. opt-out but it has been part of this module for a very long time. We might remove the inclusion of additional modules in the frontend when we start working on Gin 4.x but for now the safe way is to use the opt-out method.

    Workaround was given with disabling the library when not needed.

    When the caching bug is reproducible we should add a fix to the mentioned issue and reopen that one to fix it.

    Cheers

Production build 0.69.0 2024