Creating and saving a CSS/JavaScript injector causes a WSoD on Drupal 9

I followed the steps to reproduce in the issue description and was unable to reproduce this issue.

No step to reproduce the error message is given. It's not even clear if this is a bug report or a support request.

At least, it should be necessary to see which CSS code has been entered in the module form.

I reproduced it on simplytest.me, on Drupal 9. It was enough to enter valid CSS style and save. Unfortunately, I didn't limit the pages to which the CSS style was added, with the effect that I could not check the log for errors, but the site shown the classic The website encountered an error sentence.

Actually, it happens also when creating a JavaScript injector.

That's interesting! The steps I followed were "When I create a CSS injector rule" per (I think?) the original issue description. You're right that the original steps to reproduce were incomplete. Thanks for reproducing.

I was able to successfully create a CSS and JS injector rule on a local pre-existing D9 (9.1.11) site + Asset Injector 8.x-2.7 when trying to reproduce, so that's interesting you're able to demonstrate this bug on simplytest.me!

I tried to do the same on simplytest.me (I'm considering this module for a project, so was checking out the issue queue when I saw the apparent duplicate issues). On simplytestme I got inconsistent results, but I didn't see the WSoD that you did. I was testing with Drupal 8.9.18 on Simplytest.me

• I created a SimplyTest.me site requesting only Asset Injector 8.x-2.x-dev
• I logged in and created an Article node at node/1
• I copied a CSS selector that was present on that page
• I created a CSS Injector rule for Article content (screenshot)
• No WSoD, no errors logged
• I visited the article node and saw the CSS injection applied (screenshot)
• I created a JS Injector rule for Article content (screenshot)
• No WSoD, no errors logged
• I visited the article node and did not see the JS injection applied (screenshot)
• I clicked "Edit" on the article node and did see the JS injection applied. (I did not expect to see it applied here.)(screenshot)
• I verified there were still no errors logged

The Tugboat environment is at https://stm61268e4a4fb41-gpgxpse51b6np6ufl9qrshhwmfah4ri7.tugboat.qa for the next 12H if you want to compare this against the one you saw WSoD in :) user/pass is per the defaults for Simplytest.me

It happens only with Drupal 9. That is the Drupal version reported in the original report, which contained the following sentence.

(My Project Drupal 9.1.8 [site link])

I apologize: In the tentative of cleaning up the IS, I forgot to add that in the Steps to reproduce.

Agree, seems like it is Drupal version related. A few more simplytest.me experiments:

- Drupal 8.9.18 on simplytest.me - works as expected
- Drupal 9.1.12 on simplytest.me - WSoD
- Drupal 9.2.4 on simplytest.me - WSoD

And yet Asset Injector 8.x-2.7 + Drupal 9.1.11 locally worked fine for me, which feels inconsistent - but it was on a pre-existing local site, so IMO is best noted then ignored from the sample - just watch out in case this bug doesn't *always* manifest on 9.x environments I guess.

Having confirmed against 9.1.12 and 9.2.4 using simplytest.me, I'll leave this alone. I only meant to step in to reduce the duplicates, but I'm happy we seem to have identified a legit bug!

Consider #3169757: WSOD and Uncaught PHP Exception Exception: "Only file CSS assets can be optimized." also? Both mention the asset type being unset.

I cannot understand where exactly the module causes this issue, but the code that throws the exception shown in the IS is the following one (in CssCollectionRenderer::render()).

  foreach ($css_assets as $css_asset) {
    $element = $link_element_defaults;
    $element['#attributes']['media'] = $css_asset['media'];
    $element['#browsers'] = $css_asset['browsers'];
    switch ($css_asset['type']) {

      // For file items, output a LINK tag for file CSS assets.
      case 'file':
        $element['#attributes']['href'] = file_url_transform_relative(file_create_url($css_asset['data']));

        // Only add the cache-busting query string if this isn't an aggregate
        // file.
        if (!isset($css_asset['preprocessed'])) {
          $query_string_separator = strpos($css_asset['data'], '?') !== FALSE ? '&' : '?';
          $element['#attributes']['href'] .= $query_string_separator . $query_string;
        }
        break;
      case 'external':
        $element['#attributes']['href'] = $css_asset['data'];
        break;
      default:
        throw new \Exception('Invalid CSS asset type.');
    }

Apparently, the code is expecting just 'file' or 'external' as CSS asset type, but it receives another value.

I tried again on simplytest.me, still with Drupal 9.2.4, but this time I uninstalled the BigPipe module before adding any CSS injector. It worked: I was able to save the CSS injector without getting any WSoD.

I take it's a conflict with the BigPipe module.

I also ran into this in combination with the workspaces module. The reason for the fatal error due to the missing asset type is in asset_injector_css_alter(), that code writes a group into the $css array, even if there is no index of asset_injector in the array. So that will cause a new index with just a value of ['group' => 999], which in turn leads to the fatal error.

I'm not 100% sure if this fix is causing any other sideeffects, but so far it worked for me.

The merge request in #15 makes sense why the error could be occurring. I was able to reproduce the error by adding $css['foo']['group'] = 999; to the hook_css_alter. The result is exactly as everyone has described. I've merged the change and I'll push out a new release. I think we can call this fixed finally.