Add consistent support for the s3fs no_rewrite_cssjs setting

This seems odd... there are AdvAgg css and js files being created and stored in S3, but the ones being requested through the browser are not the same files. In fact, the ones in the browser HTML don't exist at all, and that is why they are returning "Access Denied."

However, if I attempt to load via URL some of the AdvAgg css and js files that are in S3, they load without issue.

I've found cause of the "Async Mode" error message, and have posted a separate thread and patch: https://www.drupal.org/project/advagg/issues/2972760

Please review, thanks. Continuing to investigate the rest of the issues.

While I think there may be some other possible issues, one key problem I've uncovered is the option to "Prevent more than 4095 CSS selectors in an aggregated CSS file" is not working correctly when the s3fs module is being used.

When loading a version of the site not using s3fs, the Bundler and CSS Compression tabs have references to "sites/default/files/advagg_css/parts/sites/all/themes/our_theme/css". These are included in the AdvAgg-generated files.

When using S3, the AdvAgg code has definitely created the parts, and stored them in public://advagg_css/parts/sites/all/themes/our_theme/css (we are using the s3fs takeover of "public://" rather than the "s3://" scheme). However, they are not referenced in Bundler or CSS Compression, and pages are not loading correctly because theme CSS is loading out of order from CSS included in the bundled files.

If I clear all AdvAgg caches and files, the parts files are rebuilt and stored in S3, but they are never referenced in the AdvAgg configuration.

Going to see if I can uncover any other details since this is a fairly serious issue for us.

Ok, I have a patch for review. This seems to fix the problem.

The file is stored in S3 correctly, but it is referenced in the database as a relative path. Whenever the CSS is added to the page, it is never bundled -- always added as an @import.

By adding this adjustment to the filename path to include the scheme for s3fs, it is compressed and bundled as expected.

Just for further clarity, the s3fs module has its own dirname function if you prefer to have the conditional be on the line of code where drupal_dirname is currently called. From the comments:

  /**
   * Gets the name of the parent directory of a given path.
   *
   * This method is usually accessed through drupal_dirname(), which wraps
   * around the normal PHP dirname() function, since it doesn't support stream
   * wrappers.
   *
   * @param string $uri
   *   An optional URI.
   *
   * @return string
   *   The directory name, or FALSE if not applicable.
   *
   * @see drupal_dirname()
   */
  public function dirname($uri = NULL) {

I've really dug deep into this, and realized there is a much bigger issue that needs to be addressed. It also ties together several issues I recently posted into a single patch.

The core problem is a lack of consistent support for the s3fs no_rewrite_cssjs setting. This is referenced in several places in the code, but is not fully built out to support every case.

Not only does this cause a problem by not allowing the 4095 CSS selectors, it also causes issues for advagg_relocate. The discussion we had last month (https://www.drupal.org/project/advagg/issues/2956531) will not work when using s3fs, because the relocated files don't even show up as options in the JS Compression settings.

There are also other places in the code that indirectly reference no_rewrite_cssjs that I have included as part of a single, consistent approach. The attached patch should fix all these problems. I'm open to adjusting the patch if you think there is a better way to address.

I looked into modifying the $filename value set for the $record in advagg_insert_update_files, right before the file is saved. This would allow the patch to be a lot smaller. However, given that the path changes per file (public://advagg_css, public://advagg_relocate, etc.), I wasn't sure if there is an easy way to do this.

Maybe if the file uri was passed into $file_meta_data for each file via advagg_get_info_on_files? I'd be interested to know your thoughts, thanks.

As mentioned in #2972760, after further testing I realized the "Async Mode" issue should not be part of this patch. Have created a new version that removes the code found with that issue.

See attached.