The s3fs_domain and s3fs_domain_root fields are presented in UI as dependencies of s3fs_use_cname, but the code does not properly filter if the fields have values and s3fs_use_cname is disabled.
This can cause problems in a situation where use_cname was initially enabled, and then disabled at some point in the future, but the sub-field values were never cleared. Most notably, the S3 file paths will incorrectly reference domain_root or public folders when they should not.
In the first test, configure these settings:
s3fs_use_cname = FALSE
s3fs_domain_root = 'private'
s3fs_public_folder = 's3fs-public'
Given that s3fs_use_cname is set to FALSE, the s3fs_domain_root value should be ignored and the s3fs_public_folder value should be prefixed to the S3 file path. However, what happens instead is the prefixing is skipped because s3fs_domain_root is not set to 'none' or 'root'.
In the second test, configure these settings:
s3fs_use_cname = FALSE
s3fs_domain_root = 'public'
s3fs_root_folder = 'dev'
Given that s3fs_use_cname is set to FALSE and s3fs_root_folder has a value, the s3fs_root_folder value should be prefixed to the S3 file path. However, similar to the example above, the prefixing is skipped because s3fs_domain_root is not set to 'none'.
See attached patch.
This fixes the bug that was introduced here in 7.x-2.x: https://git.drupalcode.org/project/s3fs/-/commit/b7bf6db2f096510c19bfc25...
Closed: outdated
3.0
Code
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
Drupal 7 end-of-life triage:
Drupal 7 reached end of life on January 5th.
The 7.x branches of S3FS do not have any additional planned releases.
The requests in this issue do not appear to exist in the 8.x-3.x and newer branches.