Layout Builder modal dialog is broken with Drupal 10.1+

Created on 21 December 2023, 12 months ago
Updated 30 January 2024, 11 months ago

Problem/Motivation

With Drupal 10.1+ the modal dialog to configure blocks when editing the layout design is broken.

When CSS/JS aggregation is disabled the problem doesn't occur, so this problem is related to the aggregation.

Example

An screenshot with the issue

An screenshot without the issue (after disabling CSS aggregation)

Steps to reproduce

  • Install a Drupal 10.1+ site
  • Install VLSuite shuttle module
  • Creata a new Landing (VLSuite) and go to the "Design" tab
  • Try to add a section or block, the modal is broken

Root cause

The problem is half Core half VLSuite. In the Drupal 10.1 some efforts to optimize assets where done (see Only the CSS or JavaScript aggregate URL is built during the main request. ). This is done, at least the part that generates the assets URLs, by CssCollectionOptimizerLazy. The URL to CSS/JS assets is now a request that is processed by Drupal, generating the asset if it is not already generated. The generated asset URL includes the active theme thanks to this code:

    // All asset group URLs will have exactly the same query arguments, except
    // for the delta, so prepare them in advance.
    $query_args = [
      'language' => $this->languageManager->getCurrentLanguage()->getId(),
      'theme' => $this->themeManager->getActiveTheme()->getName(),
      'include' => UrlHelper::compressQueryParameter(implode(',', $this->dependencyResolver->getMinimalRepresentativeSubset($libraries))),
    ];

The VLSuite does something tricky. To display the modal dialog with the admin look and feel, the VLSuite injects the admin theme CSS/JS dependencies in the current page (see VLSuiteModalLibraryDiscoveryCollector::resolveCacheMiss). This clashes with the core optimization because core assumes all assets are form the same theme. As a result, the URLs of the injected admin theme assets are wrong and their contents are not loaded.

Proposed resolution

Ideally, core should support this situation. However, even if this is accepted, we lot of time will be needed before it is merged into core. Therefore, let's try a different approach: VLSuite's CssCollectionOptimizerLazy can forbid that the admin assets are prepocessed, so the code that craters the problem is not run.

Remaining tasks

Validate solution and code it.

User interface changes

None.

API changes

None.

Data model changes

Admin assets will be never aggregated when using them int he modal dialog. Not a big deal, but ideally it should be avoided.

🐛 Bug report
Status

Fixed

Version

1.1

Component

Code

Created by

🇪🇸Spain tunic Madrid

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

Merge Requests

Comments & Activities

  • Issue created by @tunic
  • 🇪🇸Spain tunic Madrid

    I've found this core issue that handles the same issue: to have an admin interface in a content (or front-end theme) page

    #2195695: Admin UIs on the front-end are difficult to theme

    After q ver very quick read and some investigation I see the following approaches:

    1. Using an iframe: that was the approach of the Overlay module. One of the issues of this approach is the communication between the iframe and the main page, for example when you want live preview (user changes things on the admin UI part and the front-end theme part should be updated)
    2. Using { all: initial; }. This resets all properties of the matched elements to its defaults. I guess the idea is to use it in the admin UI container. I'm not sure how to restrict CSS rules from admin theme to the admin UI container and children.
    3. Using Cascade layer. This recent CSS functionality allows to play with the priority of CSS rules using layers. I guess this would be used together with the { all: initial; } solution.
    4. Using Shadow DOM. This is probably the best approach because AFAIK by default the Shadow DOM isolates the content of the Shadow DOM from the main CSS. Using this, the Admin UI will be placed inside a Shadow DOM with the CSS styles of the admin UI. However, because this isolation, there will be difficulties to send changes done in the admin UI to the front-end main page. For example, creating a section implies clicking in a front-end main page element that will open the admin UI in the shadow dom and then getting back the configuration or changes done in the admin UI to the front-end main page.

    I'm not a front-end dev so take what I say with a giant grain of salt. However, I wanted to leave this here as a reminder of others with more knowledge on this area.

    I guess probably it is a good idea to follow or even try to push forward the mentioned core issue as it is solving the same issue in a general way. This issue has far more chance of modifying core to, for example, allow CssCollectionOptimizerLazy to support assets of different themes not only the current one.

  • First commit to issue fork.
  • Open in Jenkins → Open on Drupal.org →
    Core: 10.2.1 + Environment: PHP 8.1 & MySQL 5.7
    last update 11 months ago
    3 pass
  • Status changed to Needs review 11 months ago
  • 🇪🇸Spain omarlopesino

    @tunic about #3 comment, I agree with you that a general approach must be done and must be provided from core. In the meanwhile, we must look for a temporary solution that let us enable CSS /JS aggregation back in sites using vlsuite modal.

    Also, I have been struggling trying to process separately additional CSS libraries added by Vlsuite modal so the admin theme is used, but it looked to be a non-ending workaround.

    After thinking about it along with @crzdev, I've just made a MR with the following solution: disable aggregation for layout builder administrative pages. In this way, the aggregation will work for the entire site except on page building, where is less priority as it is only used for admins, mostly in desktop.

    I feel this is a workaround for a contributed module as CSS /JS aggregation should work at every page. I would like to know also your opinion about whether this is good to have in the module or if a different solution should be done.

    In other side, I think having an already working solution is good for sites with css aggregation disabled, so it can be enabled again with guarantees.

    Please review, thanks1

  • Status changed to Fixed 11 months ago
  • 🇪🇸Spain tunic Madrid

    Merged, thanks!

    I've created Improve Admin interface in layout editor page Postponed to solve this issue in a general way. I'm closing this because the issue (modal dialog broken) is fixed, although we need a way to mix admin and main themes to remove the workaround.

  • 🇪🇸Spain tunic Madrid

    Crediting also CRZDEV because we discussed the solution with him, thanks!

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

Production build 0.71.5 2024