If an image is uploaded to the 'temporary://' file system and an Image style is being generated from said path, the image derivative will not be generated.
A valid usecase for why this should work is with File (Field) Paths; #2383527: Force unprocessed uploads to temporary://.
A client using Amazon S3 was experiencing slow down when using File (Field) Paths, which turned out being due to the temporary/unprocessed file being uploading to Amazon, then the processed file also being uploaded seconds later, it was determined that it would make sense for all users to have unprocessed files uploaded to 'temporary://' so as to avoid this issue, but if the field is an image field then the 'preview' image isn't generated due to this bug.
The fix is extremely simple, it's a copy and paste of the existing fix for the same issue that would occur for image derivatives being generated in 'private://'.
Patch incoming for the sake of getting the ball rolling, but I suspect that I will need to move this to D8 and supply a fix for it first, assuming the issue is also present in D8.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | temporary_image_derivatives-2560139-6.patch | 3.9 KB | deciphered |
| #6 | interdiff.txt | 3.23 KB | deciphered |
| #4 | temporary_image_derivatives-2560139-4-tests_only.patch | 1.94 KB | deciphered |
| #2 | temporary_image_derivatives-2560139-2.patch | 857 bytes | deciphered |
Comments
Comment #2
decipheredComment #3
andypostThat's could cause access to any files in 'tmp' so needs security review and tests
Comment #4
decipheredAttached patch is tests only, for the sake of failing to demonstrate issue.
Tests are copies of the existing Private file system image styles tests, including access control tests.
Updated patch to follow after testbot successfully fails.
It's worth noting that I did identify an issue in the original patch related to access control, which is remedied in the updated patch.
Comment #6
deciphered