D10 Compatibility AddCssCommand() - AJAX error for css route of webform assets

I believe there is an issue, but I can't seem to replicate it using the attached webform added via a block.

My guess is we need to change the path from /webform/css/feedback?s1agpk&s1agpk0 to /webform/css/feedback/custom.css?s1agpk&s1agpk0

First, we need to be able to reproduce this issue.

@jrockowitz Seems like the issue is reproducible only on D10 when the webform loads via AJAX. E.g. we load webform as a modal window.
ajax.js was updated a lot on Drupal 10.1

The following loadjs code breaks a solution - https://github.com/muicss/loadjs/blob/master/dist/loadjs.js#L113

Made a quick patch to solve the issue.
But we still need to cover it with tests.

The patch looks pretty good, and the broken tests need to be fixed.

Fixed tests and also fixed the cache invalidation issue.

After updating the CSS assets route a bit another logic implements for NotFoundHttpException - the fast_404 instead of the 404 system page.
The fast_404 (Fast404ExceptionHtmlSubscriber::on404) breaks the invalidation cuz it makes the response only with 1 cache tag - 4xx-response. So I had to implement a new solution for 404 response.

The last submitted patch, 8: 3389539-ajax-add-css-compatibility-8.patch, failed testing. View results →

This looks fine and needed.

I just realized that _webform_asset_alter() must also be updated to ensure custom js and css loads last.

I also think we need to update the path for JavaScript so that custom CSS and JS use similar paths.

I am not sure if the file name should /inline.css or /custom.css

Hi @jrockowitz

• Nope, we don't need it, cuz _webform_asset_alter() still should works for the updated route, we changed only the end of the route, but not the start
• I thought about that, it's not required, but I agree that it'll be fine to make both of them in the same way
• I had the same dilemma when creating the patch :) I still don't know which option is better

I think I'll implement the same way for JS this weekend.

@HitchShock, this looks great and is very close to RTBC.

I wish I had thought more about whether it should be /inline.css or /custom.css because the obvious answer is /custom.css. After all, the settings are labeled and described as 'Custom CSS/JS' via the UI (/admin/structure/webform/config/libraries and /admin/structure/webform/manage/contact/settings/assets).

Our organization just spent a couple weeks of manhours troubleshooting missing webforms.

patch #19 solves our missing webforms bug. A couple weeks of manpower flushed to figure out that we needed this patch.

patch #19 a godsend.

tested to work with the latest tagged release of the webform module and the latest minor release of Drupal 10.1 (10.1.8) on PHP 8.1

I am going to make one nitpick change and switch the code from using inline.css to custom.js.

From there, I will commit the change. Thank you for working on this.

Looks good, doesn't matter to us what the filename is as long as the bug is resolved. I would think that this fix should be pushed out sooner rather than later. This issue has already caused a lot of confusion and issues, would be best to move forward sooner than later.

Merged! I will be tagging a new beta release very soon.

@jrockowitz thank you again :)

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

This fix completely broke our webforms' custom CSS/JS because our server assumes that paths ending in .css or .js are static files and attempts to serve them accordingly (that is, without PHP). We are running Drupal 10.3.1 / Webform 6.2.7 behind nginx 1.24 using the wodby/nginx Docker image.

I believe this behavior on the Docker image's part is configurable by either no longer treating CSS/JS requests as static files (which might break the ones that actually are static files...we haven't tried it yet) or by passing static file 404s to index.php, but I feel like we're justifiably reluctant to do either one of these. Our website sees a lot of random garbage requests, and we don't want to risk those taking down our website.

It'd be nice if we had the option to use either the old routes (which never caused a problem for us) or to use the new paths in this fix.

The change in this issue has caused 🐛 Webform asset javascript (webform/javascript/webform_id/custom.js) is showing not found Active .