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

Blazy Admin CSS Enabled Blazy Admin CSS Disabled

Steps to reproduce

  1. Install and activate "Adminimal - Responsive Administration Theme" as the administration theme.
  2. Install and activate "Barrio" as frontend theme.
  3. Install module "Layout Builder Modal"
  4. Install module "Bootstrap Styles"
  5. 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.
  6. 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

lolgm created an issue. See original summary.

lolgm’s picture

StatusFileSize
new7.07 KB

Patch attached

gausarts’s picture

Yes 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 :)

lolgm’s picture

Issue summary: View changes
lolgm’s picture

Status: Active » Needs work

Thanks for the quick response and guidance :D
I will implement them.

lolgm’s picture

StatusFileSize
new3.38 KB

I'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.

lolgm’s picture

I'll have to leave for now, but later I'll send a patch with the tests fixed.

lolgm’s picture

StatusFileSize
new0 bytes

Test correction attempt.

lolgm’s picture

StatusFileSize
new7.99 KB

Test correction attempt. Correct Patch...

lolgm’s picture

Status: Needs work » Needs review
gausarts’s picture

Thank you.

To completely disable Blazy css without side effects, we can hijack $admin_css variable to FALSE.

Perhaps after this line:
https://git.drupalcode.org/project/blazy/-/blob/8.x-2.x/src/Form/BlazyAd...

If meeting LB hijack $admin_css FALSE.

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.

lolgm’s picture

StatusFileSize
new8.03 KB

Surely your method is better.
Is there anything else I can do?

Thank you very much :)

Status: Needs review » Needs work

The last submitted patch, 12: 3243817-remove-admin-css-layout-builder-12.patch, failed testing. View results

lolgm’s picture

Status: Needs work » Needs review
StatusFileSize
new8.65 KB

Correction of tests.

gausarts’s picture

Thanks.

Adding new arguments to the existing services might have 2 costs:

  1. Might break extenders (sub-modules) unless they update it as well and or we are sure we have checked the entire Blazy ecosystem if none was affected.
  2. WSOD without an empty hook_post_update to clear cache.

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...

+  use Drupal\blazy\Blazy;

-   $current_route_name = $this->routeMatch->getRouteName();
-   $current_route_name = isset($current_route_name) ? $current_route_name : '';

+  $current_route_name = Blazy::routeMatch() ? Blazy::routeMatch()->getRouteName() : '';

+    $is_layout_builder  = str_starts_with($current_route_name, "layout_builder.");
+
+    if ($is_layout_builder) {
+      $admin_css = FALSE;
+    }

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 :)

lolgm’s picture

StatusFileSize
new1.47 KB

I'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?

Status: Needs review » Needs work

The last submitted patch, 16: 3243817-remove-admin-css-layout-builder-16.patch, failed testing. View results

gausarts’s picture

My 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:

public function getRouteName() {
  return Blazy::routeMatch() ? Blazy::routeMatch()->getRouteName() : '';
}

We should improve this line in the future 3+, like using service calls. But not priority for now.

Then replace this line:

-    $current_route_name = Blazy::routeMatch() ? Blazy::routeMatch()->getRouteName() : '';
+   $current_route_name = $this->blazyManager->getRouteName();

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.

lolgm’s picture

Test correction attempt...

lolgm’s picture

StatusFileSize
new2.26 KB

Test correction attempt... Again...

gausarts’s picture

Sorry for getting back late :)

It appears the test complains about str_starts_with which accepts null, not empty string, when ::getRouteName() method passed:

+    $current_route_name = $this->blazyManager()->getRouteName();
+    $is_layout_builder  = str_starts_with($current_route_name, "layout_builder.");

Potential solutions:

lolgm’s picture

Status: Needs work » Needs review
StatusFileSize
new2.34 KB

Hi,
Thanks for the tips. I think we've come up with a solution :)

lolgm’s picture

StatusFileSize
new2.42 KB

Oops...
This is the correct patch.

gausarts’s picture

Look 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 :)

gausarts’s picture

We also need a correct check. This will do:

+    if ($admin_css && !empty($current_route_name)) {
+      $admin_css = !str_starts_with($current_route_name, "layout_builder.");
+    }
lolgm’s picture

StatusFileSize
new2.36 KB

Initially 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.

  • gausarts committed 3611308 on 8.x-2.x authored by lolgm
    Issue #3243817 by lolgm: Added CSS Admin disable option in Layout...
gausarts’s picture

Status: Needs review » Fixed

Committed. Thank you for kind contribution and patience.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.