Assets are not served over S3

I have run into this issue as well. This is a conflict between the s3fs module and this module. The workaround is to disable preprocess on all of the asset injector assets.

I'll try to work on a patch if I get the time.

Moving this to the asset injector project since I think it's an issue on that side.

When working with the s3fs module absolute URL's for CSS and JS have a path like /s3fs-css/whatever.css or /s3fs-js/whatever.js which is then reverse proxied to the S3 bucket. This is done to prevent relative links to things in the CSS and JS from referencing the S3 bucket which would cause broken links. The reverse proxy makes relative links resolve to the site domain.

The AssetInjectorCss and AssetInjectorJs classes are both calling the filePathRelativeToDrupalRoot() method, which transforms an already internal URI (public://asset_injector/css/whatever.css or public://asset_injector/js/whatever.js) into an absolute URL and then chops off the protocol and domain. This is causing s3fs internal URI's to be transformed into the reverse proxy paths (/s3fs-css/whatever.css or /s3fs-js/whatever.js) that don't mean anything internally. I understand it was done this way to transform public://asset_injector/css/whatever.css to /sites/default/files/asset_injector/css/whatever.css, but it doesn't need to be done this way. Drupal knows how to handle internal URI's when aggregating CSS and JS.

So, this patch is essentially to allow Drupal to translate the URI's (public://asset_injector/css/whatever.css or public://asset_injector/js/whatever.js) to absolute URL's when it deems it necessary.

The function that I removed was added for #2869562: Deployment does not change asset files, so it will need to be confirmed that this still works. I checked the following scenarios with great success:

1. No S3 integration, without CSS/JS preprocessing.
2. No S3 integration, with CSS/JS preprocessing.
3. S3 integration, without CSS/JS preprocessing.
4. S3 integration, with CSS/JS preprocessing.

Thanks for the patch. Sorry for the delay. #2869562: Deployment does not change asset files is still functioning correctly even with the patch. Which makes sense since this patch just adjusts the path string and not the actual functionality involved in building the asset.

Unfortunately this broke dev on a regular install, which my colleague had a hard time to track down and bisect to this commit (thanks a lot Andi!).

So reverted this.

> Drupal knows how to handle internal URI's when aggregating CSS and JS.

I did not dig into this issue yet, but this assumption from #6 is wrong, at least until #2735717: Stream wrapper reference in JS library causes error in _locale_parse_js_file() is fixed (if it ever will, which is not clear yet).

@slydevil I have no experience with s3fs, can you elaborate a bit more how s3fs plays with the rest of drupal? Maybe that way we can find a way to make that use case work without killing others.

OK i investigated this a bit and the core issue indicates this only happens on multilingual sites and can be worked around by converting to drupal-root-relative paths starting with /. Which we did, but lacking root support in a too-broad way.

Patch flying in with a shoot at this.

@slydevil could you please review the patch from #15. If it works, we can look at getting this supported.

@pookmish, it seems that #15 works with s3fs with/without css preprocessing.

Rerolled patch #15 to work with 2.16.0

#18 works for me. Thanks

While maybe not exactly the same, I believe that #3454952: Support the new assets stream wrapper on Drupal 10.1.0+ should help with this on 10.1+, at least make it store it locally instead of s3fs which is what I would expect for dynamically generated assets.

Rerolling for Asset Injector 8.x-2.21