Needs work
Project:
Drupal core
Version:
main
Component:
image.module
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
29 Nov 2016 at 18:34 UTC
Updated:
24 Nov 2025 at 11:31 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
mondrakeComment #3
mondrakeJust a proof of concept patch.
The concept is:
a) Add to the image field settings an additional setting to optionally specify an image style to be applied to the image file being uploaded. This image style could have any sort of effects - exif autorotation, metadata stripping, text overlay, etc etc. This could solve at the root #2664632: Bugs with images that include image orientation from image EXIF data: you may want to have an EXIF autorotate effect in the style you select => the uploaded file will be autorotated 'at the origin' so you can avoid having to enter the same effect in all the styles used for image styling in formatters/widgets. Quite powerful as it opens a pandora box of possibilities.
b) Apply the selected image style to the uploaded image before it is saved to final storage. Since the file upload temporarily stores the image file in the temp directory to execute validation against it, and moves it to final storage only after validations passed, I thought to introduce an additional validation function that would try to apply the image style to the temp file and produce a derivative. If that passes, derivative is moved back to the temp filename and finally stored to final destination.
This overlaps to some extent with the 'maximum resolution' settings - these could be replaced with an image style with a 'scale' effect. But this would break BC, so I just thought to run the image style validation before the maximum resolution validation.
Of course this misses tests, upgrade path, configuration dependency, etc etc but just wanted to share to see if it makes sense.
Feedback appreciated :)
EDIT: just a remark - if we take this path, uploaded images will be styled with the effects/settings defined at the moment of the upload: there's no way to recover the original image to apply a different set of effects/settings if the image style is changed afterwards.
Comment #5
mondrakeJust trying to fix failure of existing tests.
Comment #8
it-cruRe-factor #5 patch to work again with current 8.3.x branch.
Comment #9
it-cruAdd patch which works with 8.4.x and 8.5.x branches.
Comment #11
it-cruMy #8 patch works fine for 8.3.x when you use uploading of image field. But when you use something like dropzoneJS this do NOT work.
In our projects I removed the patch again and add an hook_file_validate() with validate code of this patch with a static in code configured 'upload' image style.
Perhaps a other solution for this have to be found, when better media handling is in core.
Comment #20
kazah commentedHello, @IT-Cru!
How to use your patch only for specific content type?
For example I have two content types
review, andpage.I would like to optimize images while uploading files only for
review.How to achieve this?
Comment #24
vasikeThis could achieved with the "proposal" from https://www.drupal.org/project/drupal/issues/3509597
Added as related issue.
Comment #25
tolstoydotcomIn my current case there are dozens of sites with dozens of in-house contributors who upload very large images. All those very large originals creates storage issues. Contributors are informed that they have to keep local copies of those images, so overwriting them on upload isn't an issue.
The imageapi_optimize module doesn't work on upload, but image_style_on_upload (as its name suggests) does and a basic test indicates that it will work.
That said, IMNSHO it'd be a good idea to generalize things as much as possible. Running some sort of pipeline when an image is uploaded or about to be displayed would be great, especially if it has if/else capability. E.g., if the image is landscape, put a watermark in one corner but if it's portrait put it in the other corner. If it's larger than 1000px, change the hue a bit. Etc. I haven't looked into if ECA has that already.
What would work best is something extensible that could be augmented by ECA or custom code.