Problem/Motivation
Blazy's CSS Admin helps in many cases with the admin theme, however when using it in the layout builder with a frontend theme it's practicality
unusable.
Example:
Blazy Admin CSS Enable | Blazy Admin CSS Disabled

Steps to reproduce
- Install and activate "Adminimal - Responsive Administration Theme" as the administration theme.
- Install and activate "Barrio" as frontend theme.
- Install module "Layout Builder Modal"
- Install module "Bootstrap Styles"
- Go to the layout builder and edit a field that can be formatted with Blazy, for example a Media Image, and select Blazy as the formatter.
- When configuring the Blazy formatter options you may notice the broken layout
Proposed resolution
Add a new option in the Blazy UI configuration that disables Admin CSS if the formatter was opened inside the layout builder. This option would only appear if the "Admin CSS" option was activated.
Remaining tasks
User interface changes
Added a new option in the Blazy UI configuration.
API changes
None.
Data model changes
Added new option to the configuration schema.
Comments
Comment #2
lolgm commentedPatch attached
Comment #3
gausarts commentedYes agreed, thanks.
I thought layout builder issue was resolved when I worked with Gin compat. Not sure other themes, though, or anything else I missed.
However perhaps we could simplify the checks, remove the option, and just hijack directly when the parent form is recognized as layout builder?
I am away from laptop now. I would leave it to you.
Option 1:
Please verify, when you dump the form array, is there anything that can be used to identify layout builder? If so, just disable directly admin_css setting. No need for route nor option. Last time I worked with GridStack, Slick Browser I had at least useful properties like fields.
Option 2:
If the above is helpless, willy nilly we go with route checks as you did, but please remove the option. Just hijack directly.
We should stop playing nice for sure :)
Comment #4
lolgm commentedComment #5
lolgm commentedThanks for the quick response and guidance :D
I will implement them.
Comment #6
lolgm commentedI've been looking for a better alternative to know if the form was being opened in the layout builder other than the route name, but I didn't find anything.
The associated patch is, as suggested, without the option, it directly removes the style if the form is opened in a layout builder route.
I just had a doubt, as I always use the same theme setup, I always come across this problem in LB, but isn't there any theme that takes advantage of Blazy Admin CSS within the layout builder forms? By removing directly without giving the user a chance to choose we could be messing up some layouts.
Comment #7
lolgm commentedI'll have to leave for now, but later I'll send a patch with the tests fixed.
Comment #8
lolgm commentedTest correction attempt.
Comment #9
lolgm commentedTest correction attempt. Correct Patch...
Comment #10
lolgm commentedComment #11
gausarts commentedThank you.
To completely disable Blazy css without side effects, we can hijack
$admin_cssvariable toFALSE.Perhaps after this line:
https://git.drupalcode.org/project/blazy/-/blob/8.x-2.x/src/Form/BlazyAd...
If meeting LB hijack
$admin_cssFALSE.The obvious side effect is double checkboxes as seen in your capture.
Looks like we need to adjust the conditions at particular Elvis lines there, my faults, none yours.
But the suggested hijack will do for now.
Comment #12
lolgm commentedSurely your method is better.
Is there anything else I can do?
Thank you very much :)
Comment #14
lolgm commentedCorrection of tests.
Comment #15
gausarts commentedThanks.
Adding new arguments to the existing services might have 2 costs:
IIRC I had resolved the first by avoiding extending it, but not sure if I missed one.
The less riskier will be these:
https://git.drupalcode.org/project/blazy/-/blob/8.x-2.x/src/BlazyManager...
This will be likely the entirity of your patch.
Then you can get rid the arguments, tests, methods.
Your approach is undoubtedly better, but riskier to break the ecosystem unless you have time to check each sub-module :)
Comment #16
lolgm commentedI'm realizing the problem, I think the suggested approach is great to avoid problems in this case.
I'm new to this world of contributions, thanks for your help and guidance. Sorry for the extra work.
Would it be better for you if I created a merge request?
Comment #18
gausarts commentedMy faults :)
I put too many traps aka tests to help me avoid this kind of mistakes. Dealing with static methods is one of the problems here.
Untested, but perhaps we should add a new cloned method to BlazyManagerBase:
We should improve this line in the future 3+, like using service calls. But not priority for now.
Then replace this line:
Feel free to give a shot.
If still fails, feel free to elaborate more for other solutions, or please wait for me to get back to this later this weekend.
Thanks.
Comment #19
lolgm commentedTest correction attempt...
Comment #20
lolgm commentedTest correction attempt... Again...
Comment #21
gausarts commentedSorry for getting back late :)
It appears the test complains about
str_starts_withwhich acceptsnull, notempty string, when::getRouteName()method passed:Potential solutions:
strpos, yet forgiving, like here: https://git.drupalcode.org/project/slick/-/blob/8.x-2.x/src/SlickManager...!empty($current_route_name) &&before executingstr_starts_with?Comment #22
lolgm commentedHi,
Thanks for the tips. I think we've come up with a solution :)
Comment #23
lolgm commentedOops...
This is the correct patch.
Comment #24
gausarts commentedLook good, thanks :)
If I may ask, I preferred your previous one, only negated:
+ $admin_css = !str_starts_with($current_route_name, "layout_builder.");Less lines, since it returns bool. But okay, too, with the last one, no big deal :)
Comment #25
gausarts commentedWe also need a correct check. This will do:
Comment #26
lolgm commentedInitially I thought of going for this more minified approach, hence the incomplete patch... But as it didn't seem very easy to understand for future maintenance changes, I left the idea aside.
But with the comment above I believe the suggested approach is cleaner and more elegant.
Comment #28
gausarts commentedCommitted. Thank you for kind contribution and patience.