Provide a module for serving agregated CSS and JSS from local public filesystem instead of S3 when option "use_s3_for_public" is used

Nice, thanks!

Tested this one and it works perfectly. Would be great as a sub-module.

Cheers

Tom

This is not a proper patch.

Initial attempt to port above module code into patch.

I like this solution. I don't want to be charged for each time the aggregated files are saved or accessed, and it seems like they are never deleted. When I went to deal with this issue I deleted 800+ files from my css folder.

The one issue I see is on line 49 in src/Asset/PublicNoS3AssetDumper.php the `FILE_EXISTS_REPLACE` is deprecated and should be `FileSystemInterface::EXISTS_REPLACE`.

I'm interested in why FILE_EXISTS_REPLACE is called because FileSystemInterface is used up on lines 30 and 32.

Thanks for this.

https://git.drupalcode.org/project/s3fs/-/merge_requests/2 contains the following:

- #7 resolved
- adds support for optimized advagg files as well

I have found a problem with the mr.

https://git.drupalcode.org/project/s3fs/-/merge_requests/6 contains the following:

- #7 resolved
- adds support for optimized advagg files as well

Considering that version 8.x-4.1 is compatible with Drupal 9.x, can I assume that by changing "core_version_requirement: ^ 8.8 || ^ 9" in s3fs_localagg.info.yml the module will work with Drupal 9.x as well?

This has been a lifesaver, so thanks for everyone's work on this!

At the moment I find myself wondering if this is better spun off into its own companion module instead of as a sub module inside s3fs.

The main reason being that this does not appear to me to be compatible with multiple server deployments which has been historically a core goal of the s3fs module. With single servers this appears it will work fine, but once multiple frontends get involved I belive we will end up where disk does not match the Cache causing issues.

I believe the first server to load the content will generate the CSS file but a second server would load just the cached object which would not regenerate the CSS file.

This does have a nice advantage that should a single server deployment ever need to go to multiple servers the module could just be removed and S3FS will be back to normal.

Needs work on compatibility flag and discussion.

I have added a new patch with `core_version_requirement: ^8.8 || ^9` for Drupal 9 compatibility.

Edit: I was a bit hasty here. The patch does not work - seems to be an issue:

PHP message: Error: Class 'Drupal\\s3fs_localagg\\StreamWrapper\\PublicNoS3Stream' not found in /var/www/web/core/lib/Drupal/Core/StreamWrapper/StreamWrapperManager.php on line 154

Updated patch to include `core_version_requirement: ^8.8 || ^9`. I'm using it with D9.2.7 and s3fs 8.x-3.0-beta3.

Tested patch in #27 and seems to be working fine, serving files from the public file system instead.

Unfortunately the performance offered in the version included in the merge_requests/6 comment #22 has not been improved yet.

The performance is spectacular and it also kept all the css/jss files, including those in the optimized folders, in the local file system of the web instance.

As noted last July in comment #25 this code to my knowledge conflicts with the core principals of the s3fs project, that the module provides support for multiple server deployments. Due to that reason I still do not believe this code should be added to the project.

I would suggest if one has only a single server deployment it may be worth considering placing all files on s3:// and use public:// only for css/js and other features that need the files locally. That should solve the low level concern without needing an additional module (with additional code and possible failure points) to be enabled.

However even if we do not implement this code in s3fs and if one does not want to utilize the s3:// scheme instead of the public:// stream it is still possible for anyone to create a new project from this code which I would suggest is the best course forward for this feature.

I will leave this issue open for another 14 days to allow a chance for anyone to provide a preliminary solution to the concerns previously raised or to spin it off into its own project before closing as won't fix.

@cmlara I am evaluating this solution but also hear your points. The issue I'm finding is that, when aggregating css, paths that are on the template css or modules, point to themes/foo or modules/bar. Disabling css/js aggregation makes the css properties to point to the webserver instead, but when aggregating, they look to the themes/ folder on S3, so I need to upload all the themes and modules' images to S3 to make this work? I much rather serve all the theme and modules files from the site.

Edit: this https://drupal.stackexchange.com/questions/304106/advagg-with-s3fs-relat... seems similar to what I'm observing (note, I've got CNAME enabled but no advagg)

@pcambra it could be you are experiencing #3241554: Non-relative paths are not re-written to reference the Drupal host in css/js aggregation. which is an issue of incorrectly specifying an absolute path instead of a realtive path in url references.

If it isn't that issue I would suggest you open a new bug report so that it can be looked at closer.

Edit: Grammar.

Ah that makes sense @cmlara, I fixed the absolute paths on CSS and all works as expected, thanks for the help and sorry for hijacking the issue!

As noted previously, while I can see this code could be be useful for some sites, I do not feel its a good fit for inside the core s3fs module given the limitations it has.

I encourage anyone who wants to continue this code forward to consider opening a new project for it by following the procedure in How to create a new project and tagging it a part of the s3fs ecosystem so others may find it.

Per #30 closing this as Won't Fix.

Modified patch to add Drupal 10 support.
core_version_requirement: ^8.8 || ^9 modified to core_version_requirement: ^9.5 || ^10