-
Notifications
You must be signed in to change notification settings - Fork 5
FR: Allow images to be resized on upload #1528
Comments
Oh God yes, this is my #1 FR Not much point selling a CMS on it's ability to version control everything when clients upload 2gb of photos in 12 months on a tiny website (who's damn idea was 20mb jpgs). |
More robust handling of large, bad, and lots of images would be a real improvement. Sanitising filenames was a big plus in protecting Statamic from clients uploading stuff, but large images is another weak point. Resize on upload (which would be a cool feature) is not necessarily the catch-all for this. There are legitimate reason for having high res images so there needs to be some control. For example we have a site where the client wants to allow resellers to download high res images. The asset viewer needs to be able to handle these type of images without causing it to hang. |
👍 for this - it is an easy way for clients to break the asset browser at the moment, there needs to be a check for large images and if they are over X size the asset browser should just not attempt to make a thumbnail for them |
In order to resize the image we need the image in the first place, and therefore the memory needed to resize it. I'll research this more, but do you guys know how others handle this? Client side resizing? We could add a way for you to specify the max file size and prevent uploading in the first place. |
@jasonvarga there's two options:
Or both. |
No idea if this will help but on V1 I was using the filemanager addon (https://github.com/servocoder/RichFilemanager) and it resized all images on upload without any issues (I'm guessing via imagemagick?) |
Can the size just be checked and if it's over X then a thumb is not generated? |
haven't tested this but it looks interesting? |
@Rockethouse looks perfect |
So in 2.6.7, the memory issue should be solved, which is the root of this issue.
If you need a smaller version of an image, you can create presets which get created on upload. If this causes you to run out of memory, you're able to queue them. On your front-end, where you need the smaller version of the image, you can use those presets. I prefer keeping the original images that are uploaded, as I agree with this comment from @lukeagsmith
If you're worried about a giant repo as per @anthubbard 's comment:
Then you can potentially gitignore your assets directory. You may also get creative with an addon or two that could potentially use Glide to resize the image and replace the original one. ❤️ |
Hi Jason, this is perfect in terms of resizing but I think my point still stands - you sell Statamic with the value that you can VC your entire website - I'm a big big fan of the fact that I can restore a backup easily and perfectly per website within about 90 seconds from the last GIT commit. In the event of an emergency / issue, if I restore a backup from the GIT branch I don't want to have to chase down assets from the client with all the hassle of making sure I have the right image in the right folder etc etc. Not having to think about it at all is one of my favourite things about Statamic. Is there a way you could add something simple in the yaml settings like:
When uploading - then we can choose to keep it or discard it if we want? Ant |
You can version control the assets right now. Nothing stopping you. If they're big images then they're big. Disk space is cheap though. I'll reopen this and leave it as a feature request for you. |
Hey this issue isn't with disk space which is cheap - it's with 2 problems:
Thanks for reopening. If I could gitignore files over a certain size I could use that but it doesn't exist. Ant |
If you have have an image manipulation set up, I quite like the idea of having a |
|
Is this no longer a thing? I don't see anything in the docs about resizing images on upload. |
WordPress implemented this back in 2019: wordpress.org/introducing-handling-of-big-images-in-wordpress-5-3 They create a scaled down version when an uploaded image is larger than 2560x2560px, and then uses that as the "original". It still keeps the original around. It is possible to turn this feature off, and set a custom largest allowed size. I think this would be a cool feature for Statamic as well! Easy to have everything configurable in On a site I had a very large image (8000x8000-ish) and Glide really had to work when loading a page with that image and parameters. Had it been working with a scaled down version, it wouldn't have been as demanding. I know there are other ways around this, with presets and caching to disk, but still. Maybe something to consider? 🙂 |
Feel free to open a feature request for Statamic v3 at https://github.com/statamic/ideas . |
Large images seem to cause Statamic issues, including running out of memory, unserialize errors, etc.
Would be great if Statamic could resize the images on upload to prevent large images from sneaking in.
The text was updated successfully, but these errors were encountered: