- 🇧🇪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.
- 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.
- 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
over 1 year ago 4:27pm 15 September 2023 - 🇨🇭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