Website error Exception: "Only file CSS assets can be optimized"

Here's a patch to workaround this issue.

Ideally it would be nicer to consider the include invalid cache and rebuild the asset or something...

The Needs Review Queue Bot → tested this issue.

While you are making the above changes, we recommend that you convert this patch to a merge request → . Merge requests are preferred over patches. Be sure to hide the old patch files as well. (Converting an issue to a merge request without other contributions to the issue will not receive credit.)

@djsagar Why move it to 11.x-dev it's a bug, did the policy change or doesn't it get applied to the latest release's branch? I maybe missed a memo

Found the memo :) https://www.drupal.org/node/767608#d8-minor →

Thanks for reporting. Will need a test case showing the problem.

@smustgrave any hints at where tests of this nature should go or could extend?

Test Scenario:

• External Library + minified included in the URL = Fail as expected
• External Library + without minified included in the URL = Skipped

Maybe in Drupal\FunctionalTests\Asset;

Also doesn't have to be it's own test, could be an additional assertion somewhere.

Does it make sense to relocate this change to `\Drupal\Core\Asset\CssCollectionOptimizerLazy::optimizeGroup` similar to the JS approach? https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal/Co...

I am reporting a similar (as it seems) issue when I visit the Resend page of a webform.

It occurs with Claro and Gin themes. When I try with eg. the Bootstrap admin theme, the issue is not present.

These are the errors I get:

1. Only file JavaScript assets can be optimized. in Drupal\Core\Asset\JsOptimizer->optimize() (line 31 of /var/www/html/docroot/core/lib/Drupal/Core/Asset/JsOptimizer.php).

2. Symfony\Component\HttpKernel\Exception\BadRequestHttpException: Invalid filename. in Drupal\system\Controller\AssetControllerBase->getGroup() (line 224 of /var/www/html/docroot/core/modules/system/src/Controller/AssetControllerBase.php).

Error logs on a few of my sites were getting filled with warnings and I could not find culprit in backtrace. Applying this patch to core (#23) has resulted in clean logs, finally!

Thanks for this great patch. I've attached the modified patch to also affect JavaScript.

I have the same errors in the log and now I am wondering how to fix it.

@joelpittet You mentioned that you had assets that were type: external AND minified: true and so you removed the minimized there. We have one such asset, the better_exposed_filters → library. But I am wondering why minified: true shouldn't be set for external libraries. There is a example of both attributes set in documentation → under minified, with the description

Whether the asset is already minified. Default: false

The asset in your example (https://cdn.ubc.ca/clf/7.0.4/css/ubc-clf-full-bw.min.css) seems to be already minified, so why not setting minified: true?

@osopolar that’s a really good point — I should know better than to make assumptions about how this works. I was under the impression minified was an action to be taken rather than a descriptor. But you’re right, the docs clearly state otherwise. Looks like I’ve been shooting myself in the foot here! Thanks so much for pointing it out.

That said, I still think the page-cached asset URLs are a problem, regardless of my incorrect understanding. I’ll try to update the issue summary to reflect that.

Yes minified describes the library, not what to do with it.