Provide theme support for Claro

Thanks for reporting this. The original issue that added administrative-style theming for the modal is #3042907: Use admin theme for forms. As indicated in that issue's discussion, since the modal appears in the context of the front-end theme, a special dispensation is needed for this to appear like an admin theme, and it cannot automatically take on the characteristics of whatever admin theme the site is using.

As you indicate at the end of your comment...

I feel maybe this ticket is already irrelevant as I've found a temporary fix/workaround, and a more generic "Update Layout Builder Modal for Claro" may be needed.

... this probably should be categorized as a feature request, rather than a bug. I've updated the issue title accordingly.

I disagree with Layout Builder Modal not being D9 ready due to this, as Claro is still in beta and not enabled by default, but I agree that we could/should support it, as it's in core, and intended as the Seven replacement. Thanks for rescoping Mark!

Alpha patch for supporting Claro theme.

Alpha patch for supporting Claro theme, with the CSS files

Agreed with the previous post that the most recent patch is incomplete. Based on just the screenshot above, it appears that some theming elements of Claro (such as the titlebar) are coming through, but many other elements are not.

I'm working on the same goal in https://www.drupal.org/project/media_library_theme_reset/issues/3100124, and have observed that, in comparison to Seven, Claro does significantly more manipulation (addition) of classes to elements (see https://github.com/drupal/drupal/blob/9.2.x/core/themes/claro/claro.them...) and even manipulation of what HTML should be on the page (see https://github.com/drupal/drupal/blob/9.2.x/core/themes/claro/claro.them...).

This presents additional challenges for achieving a theme reset in the context of Layout Builder Modal. Specifically, we want to do the same CSS class additions and HTML manipulations that Claro does via preprocess functions, but the preprocess pipeline lacks the ability for us to limit that manipulation context to just the modal.

This could be partially solved by adding custom CSS that mimicks Claro, without relying on the CSS classes that Claro is adding. This, however, would create a very large maintenance burden on the part of this module to keep that custom CSS in-sync with Claro, and it doesn't solve the issues of HTML manipulation.

I'll provide updates on the progress I'm making in #3100124: Add support for Claro and hopefully we can apply a similar approach to Layout Builder Modal.

Just wondering if anyone has a solution for this? Seven really doesn't work for us and the front end theme is way off.

My testing has been limited so far, but I've had some early success with Layout Builder iFrame Modal, which looks to skirt these CSS issues by displaying forms as rendered by Drupal in the admin theme (Seven, Claro, Gin, whatever) inside an iFrame.

Bumping this as I am also using this with D9 and Claro.

Ideally, and I don't have any grasp on the challenges involved so take it for what it's worth, this module should use the admin theme but be theme-agnostic, so it is compatible with any future default admin themes but also any other admin theme that a user might employ or create.

I'll test out "Layout Builder iFrame Modal" but in general I prefer the approach of this module, so I'd love to see it fixed.

I think everyone, maintainers included, support the idea that the modal should render with whatever administrative theme the site is using. The fact that Layout Builder Modal styles it with Seven (and that this issue proposes giving an option to style it as Claro) represents what the maintainers understood as the only solution to the problem.

The idea of using an iframe to achieve this was raised but apparently never pursued (facepalm). See https://www.drupal.org/project/layout_builder_modal/issues/3042907#comme... . What followed from that thread was a substantial amount of theme overriding to suppress elements of the active (front-end) so it wouldn't interfere with the Layout Builder form.

The fact that layout_builder_iframe_modal achieves this without any CSS overrides raises an existential question for this module. Since both modules are trying to solve the same problem with the same UI (a modal), and that is all the modules do, I don't see a reason for two implementation approaches to persist.

Possible next steps:
1. Confirm that there are no real differences in the purpose between layout_builder_modal and layout_builder_iframe_modal. (Mark LaCroix, can you elaborate on "In general I prefer the approach of this module"?)
2. Get in touch with the maintainers of layout_builder_iframe_modal and see if we can join forces to maintain just one module.
3. Open a new issue for layout_builder_modal called "Render Layout Builder content in iframe" and put this theme override issue on hold until that has been investigated.

(Mark LaCroix, can you elaborate on "In general I prefer the approach of this module"?)

First: my experience using iframes for anything is that it makes things a little slower. Anytime I can avoid a page load (or similar) when editing a Drupal site, I'm happy. Second: I suspect it would be a little easier for site builders to muck about with the CSS to customize the modal a bit (that is, not having to fully support admin elements in their front-end theme) without the iframe.

That said, these are basically philosophical issues, not practical ones. I've now tested out Layout Builder iFrame Modal and while yes it is a hair slower, I guess I ultimately prefer that it works with no fuss. Perhaps it is worth merging the two modules (giving users a "use iFrame" toggle would be best of both worlds, but would no doubt increase the complexity of the resulting module).

I have looked into Layout Builder Iframe Modal, and it looks like a solid, well designed module. Great work. I'd be open to merge its functionality into Layout Builder Modal behind an option, e.g. "Render modal in an iframe"

Another option, is to explore Shadow DOM which could be an alternative to iframes. I've seen discussions around Shadow DOM in Drupal core issue queue a while back.

Related note: I evaluated the module Layout Builder Admin Theme (https://www.drupal.org/project/layout_builder_admin_theme) as a solution to this issue. While it does nicely solve the issue of the editing interface in Layout Builder (and is compatible with Layout Builder Modal's modal), it also changes the theme for the "Layout" tab to the administration theme, and therefore it will not represent an accurate version of what the page will look like in the active (front end) theme. You would have to save the layout to see what the content would render as. This is probably unacceptable for many sites.

Chiming in to say that I also support merging the two modules. A checkbox "Render modal in an iframe" sounds great.

That said, I also believe we should implement a Claro styling as we did for Seven. This would improve the out-of-the-box experience.

Hi!

I'm using this patch on version Drupal core 10.1.2 and Layout Builder Modal 8.x-1.2.

My modal needs 2 clicks to be openned and I receive the next error on the first click:

ajax.js?v=10.1.2:1119 An error occurred during the execution of the Ajax response: The following files could not be loaded: /modules/contrib/layout_builder_modal/theme/claro/css/table.css?s0icd922

I noticed that is missspelled and is missing an 's' after 'table.css'. It should be 'tables.css'.

I'm attaching the new patch. Is exactly the same, with this error fixed.

Thanks!

Just tried the patch #22, it doesn't work for me.

First the library is not even added for me, it might be a different bug. I suspect that because the configure block is an ajax request, the #attached from the form are not added into the page.

But even when adding manually that into a preprocess_page, the styling is definitely not great.
$variables['#attached']['library'][] = 'layout_builder_modal/claro';
I noticed some changes though, like fixing the z-index of the modal, or button styles, but lots of it doesn't look good, wrong color of the modal header, close button invisible, selects/checkboxes are not styled.

There is some styles:

.ui-dialog .ui-icon.ui-icon-closethick {
  margin-top: -8px;
  background: url(../../images/core/ffffff/ex.svg) 0 0 no-repeat; }

We have no images folder into /modules/contrib/layout_builder_modal/theme/images/core/ffffff/ex.svg

EDIT: For those who needs a fast solution, I just uninstalled the module and switched to layout_builder_iframe_modal. That fixes so many issues and look way better, no need to spend time restyling what your theme impacts. And looks awesome with Claro.
There is only one month left before seven disappear from core, so I doubt layout_builder_modal will be ready on time.