The theme must be passed as a query argument

This looks the same as 🐛 AssetControllerBase.php - "The theme must be passed as a query argument" Active from July.

@miiimooo

Are you using the LiteSpeed Cache module by chance?

I just upgraded to D10 and I am getting this same error. Some pages, load fine and some load but the css/jss files don't load which makes the pages style-less.

After uninstalling the LiteSpeed Cache module, everything works fine.

I was getting this error with Umami profile/theme and then updated to 10.1.8 and now it seems okay.

I had this same exact problem, with the same exact error message, until I set the correct permissions on sites/default/files, and it went away by itself after a couple of cron runs.

Because of the way my web server is set up, I needed to set the tmp and sites/default/files directories to 775 rather than 755.

I am only here to type this response as I was here looking for a solution, and when I clicked for the log file to copy the error, the problem was fixed.

For me, this problem is definitely being caused by Cloudflare. As soon as I take the site off Cloudflare and set it on "DNS Only" then it is gone immediately.

I just wanted to jump in here quickly and rebut @cilefen's theory that this issue is the "same" as #3377310. It's definitely not. 3377310 is specifically about caching issues, with thoughts put forth that it might be caused by Varnish, WAFs, and other enterprise-level factors. I can rebut it because I'm getting the same error consistently in a range of environments (both hosted and in Docker/Lando containers) and I definitely don't have any kind of fancy cache installed. It's something else.

For the record, here's what Watchdog says on one of them, in this case Drupal 10.1.8/PHP 8.1.27 under Lando:

Location	https://phase4.lndo.site/sites/default/files/js/jquery-2.1.0.js
Referrer	https://phase4.lndo.site/?_webform_dialog=1&token=6mBRf5hY-hXeiCNGLUokvKRfltOSTE1sTCMdJ2CWu44
Message	Symfony\Component\HttpKernel\Exception\BadRequestHttpException: The theme must be passed as a query argument in Drupal\system\Controller\AssetControllerBase->deliver() (line 132 of /app/web/core/modules/system/src/Controller/AssetControllerBase.php).
Severity	Warning

In my case, I was able to get this warning to go away by giving it a dummy file at sites/default/files/js/jquery-2.1.0.js. (That didn't actually fix my problem, but it made the message go away.)

But if anybody else ends here the same way I did -- by Googling the error message we see in Watchdog -- I wanted them to understand that whatever caused this problem is still out there. This bug has not been resolved.

This issue exist on several sites after Upgrading to 10. This issue is fatal as it is not repeatable and really rare, but it crashes the sites output until someone does a cache refresh.

As Drupal does not even address this issue as relevant we have to patch the core file to run a cache refresh when the error is created. Nasty as it is.

to confirm, we also have this bug, Drupal 10.2.4, happened both on DDEV and on the web server, no extra caching modules (Varnish, Cloudflare, LiteSpeed, etc.) in use. the only way to prevent it from causing issues on the front end (sometimes the aggregated css or js files are broken, and this causes javascript errors, in our case) is to turn site aggregation off entirely.

People are complaining at 🐛 AssetControllerBase.php - "The theme must be passed as a query argument" Active that the issue still occurs.

Let this be the issue for continuing work.

The issue summary needs updating with precise reproduction steps to proceed.

It isn't clear how this issue is different from 🐛 AssetControllerBase.php - "The theme must be passed as a query argument" Active .

In every case I've seen so far, the file urls for aggregated assets are missing the entire querystring - they are old urls for long-deleted JS and CSS aggregate files.

In our case, I dug through the logs and can see the urls are from a previous version of thee site running Drupal 7. The page loaded by the client (iPhone OS 15_0 Safari) was at least 7 months out of date. The client is at fault for ignoring cache directives. Possibly the iPhone was trying to preload assets it expected to need even though we never told them to.

I'm not sure this explains all of the cases described in this issue. Is possible for Drupal core to include links to aggregated assets on the page without those querystrings? I poked around but couldn't see where it was happening.

If it is not possible, then it is still a problem when clients and caches ignore directives or strip the querystring for some reason, but this issue could be downgraded. Maybe all we can do is write good directions for configuring caches.

@cellear

sites/default/files/js/jquery-2.1.0.js

The sites/default/files/js directory is for Drupal's JavaScript aggregation, this looks like something (maybe a contrib module) is expecting jQuery 2 to be in that directory. The reason you got the error is that when that file doesn't exist, Drupal tries to generate a JavaScript aggregate, but because it's an invalid URL, it logs it as such. If aggregation wasn't configured at this URL, you'd get a 404 instead of a 400, but you'd still have the same problem overall.

You should try to figure out what is generating the link to that location. Ideally, nothing would be relying on jquery 2.1 at all, because jQuery 3 is in core and they should use that instead of loading double jQuery. 🐛 ExceptionLoggingSubscriber should not log HTTP 4XX errors using PHP logger channel Needs work stops the 400 error (which is correct in this case) being logged as a PHP error (which was not) and was committed several months ago. Grepping the code base for jquery-2.1.0.js is probably the place to start tracking it down.

@earthangelconsulting if you can reproduce this with ddev, can you post steps to reproduce from a clean install of Drupal core? - i.e. which if any contrib modules are required, what configuration, what page it appears on?

@catch ... sure i can try, once my current workload lightens up a tiny bit. this error i had (both on DDEV and server) was with a fairly complex site, so figuring out which contrib module starts off the error will take a bit of experimenting. it's definitely necessary though. i will keep you posted.

We've had this error showing in our logs since we upgraded from D9 to D10 last week.
I thought it was due to old users having old pages opened and requesting old aggregated CSS / JS… and that it would progressively disappear. But it seems that it could be increasing actually..
I see this error for aggregated CSS and JS files, but I also have it a lot for the following requested files:
js/lazy.commerceui-wc.utils.js
js/lazy.commerceui-wc.themes.js
js/lazy.commerceui-wc-buying-options.js
js/lazy.commerceui-react.price-history.js
js/lazy.commerceui-react.price-activity.js
js/lazy.commerceui-react.theme.js
js/lazy.commerceui-react.layout.js
js/470.js
js/273.js
js/763.js
js/256.js
I have no idea what these are about. We have Drupal Commerce installed, but I can't find any occurence of these words anywhere in the source code… this is really weird.

@Nicolas Bouteille this is probably bots trying to find old vulnerable versions of random libraries. I often see 404s for obvious wordpress files on Drupal sites. If they weren't in the js directory, they'd just be 404s.

Could have been you're totally right, but these are files requested by logged in users with legit IP and JS files loaded from a legit referer url :/

But when I visit the referer myself I cannot reproduce the error

After some digging it looks like adding (and expecting) parameters theme, delta or even language in the aggregated file url was not in place in Drupal 9.
From what I could figure out, creating the aggregated file url is done in core/lib/Drupal/Core/Asset/CssCollectionOptimizer->optimize() for D9 and now in core/lib/Drupal/Core/Asset/CssCollectionOptimizerLazy->optimize() for D10
Only the D10 version adds these parameters.

Checking for parameters theme, delta and language is done in core/modules/system/src/Controller/AssetControllerBase->deliver() in D10 and no similar code can be found for D9
It seems this was delt in D9 by core/lib/Drupal/Core/Asset/AssetResolver->getCssAssets() which first line is actually automatically retrieving the active theme…
$theme_info = $this->themeManager->getActiveTheme();

So it seems normal that users visiting pages generated by D9 in the past trigger these errors in the new D10 code.

But what's weird is it seems to me that these errors are triggered by users who have been visiting the site multiple times since we've upgraded to D10 so I would definitely expect these errors to progressively disappear… yet they don't seem to... but it's hard to be certain...

@Nicolas Bouteille yes the aggregation creation mechanism changed in 10.1.x to use the controller.

The actual files that are created in those directories look like this: js_ma6N912ufG6xKNMQcww0c5e8PFJemxYLWmGmqFWLxNQ.js, there should not be requests for individual files against the directory at all, which is why I suspected bot requests, but if it's real users, it could be some kind of interaction with a contrib module or custom code - although if you can't reproduce when visiting the same URLs it's going to be tricky to track down.

UPDATE : in the end the number of errors that appear in the logs seems to clearly decrease, so this clearly seems to be due to Drupal 9 pages being kept open on an old tab that requests CSS and JS files the old way not compatible with D10. So not much to do here, the errors should fade away progressively...

@Nicolas Bouteille the requested assets such as js/lazy.commerceui-wc.utils.js, js/lazy.commerceui-wc.themes.js. etc. are not actually linked to old D9 pages. We have the issue on our production instance, after some research, it seems those requests are generated by edge shop comments after the release https://learn.microsoft.com/en-us/deployedge/microsoft-edge-relnote-stable-channel#version-1240247880-may-2-2024.
The issue has been fixed, but still not all the edge users apply the update: https://github.com/MicrosoftEdge/WebView2Feedback/issues/4534#issuecomme...

thanks for the update!

I'm also running into these log entries now and the URLs it complains about don't seem to be old.
In our case, I can see that the &'s in part of the URL are encoded like this:
&amp%3Btheme=example_theme&scope=footer

That seems to cause the issue for us. Any ideas how and where that can happen? The strange thing is, that not all &'s are affected. And %3B (escaped ;) implies the URL is double-encoded somewhere.

We are also seeing this error pop up every couple of minutes in our drupal-logs for at least one of our websites. This certainly seems like something that needs to be resolved.

Fixes are made on on 11.x (our main development branch) first, and are then back ported as needed according to our policies.

Even I am facing this issue on a regular basis on one of the sites I am working on.

Is the Status of the issue correct?

Yes the status is correct. The issue summary needs updating with precise reproduction steps.

Based on the change record → and the fact that I was using nginx/php-fpm I updated my conf file and am no longer seeing the error.

From

location ~ ^/sites/.*/files/styles/ {
  try_files $uri @rewrite;
}

To

location ~ ^/sites/.*/files/(css|js|styles)/ {
  try_files $uri @rewrite;
}

In case it helps anyone else.