By adding additional metadata field to the file objects in the S3 bucket we can download files with the original name.
This is needed when multiple files with the same name are uploaded and Drupal renames files by adding prefix "_0", "_1", etc to the file.
In the case where the file needs to be downloaded with the original name then that metadata needs to be added to the file object in the S3 bucket.
['Content-Disposition' => 'attachment; filename="' . $post['filename'] . '"'],
This patch is made for Cors upload functionality.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | interdiff_2-3.txt | 1.52 KB | hkirsman |
| #3 | flysystem_s3_add_metadata_content_disposition-3131517-3.patch | 1.07 KB | hkirsman |
| #2 | flysystem_s3_add_metadata_content_disposition-3131517-2.patch | 852 bytes | mikkmiggur |
Comments
Comment #2
mikkmiggur commentedComment #3
hkirsman commentedImages and probably some other types as well should not be forced to download. Adding mime type to all files and before enforcing content-disposition, check if it's of type 'application/*'.
Comment #4
leon kessler commentedCould you explain a bit more why this is required?
If Drupal renames a file, because there is a duplicate, then the file must be stored with its new name in S3.
I've referenced another issue here, related to the file renaming in CORS uploads.
Comment #5
mikkmiggur commentedOne use case for that is when we have downloadable software stored in the S3. For example something like that software_name.exe.
In case you need to upload the same file again for whatever reason (hotfix, wrong file, etc) Drupal will upload it with prefix _0, _1, and so on.
But we need that users can still download that file with the same original name and without Drupal created prefix.
Maybe it will be more correct to have a settings checkbox for that functionality to turn it on/off.
Comment #6
leon kessler commentedTo me, this sounds like you have bespoke functionality that should probably be implemented outside of this module. Eg you could look at using https://www.drupal.org/project/file_replace
We are only trying to replicate Drupal cores file handling and not really adding any additional functionality on top (other than using of a different file system).
That being said, I still don’t see an issue with the patch, and will take another look at it soon (as I’ll be working on updating some of the CORS file handling).
Comment #7
mikkmiggur commentedIf it feels too specific functionality then please let's close this ticket "Works as designed" and we will continue to heave that functionality with that patch file.