Skip to content
This repository has been archived by the owner on May 9, 2023. It is now read-only.

FR: Allow images to be resized on upload #1528

Open
edalzell opened this issue Jul 27, 2017 · 18 comments
Open

FR: Allow images to be resized on upload #1528

edalzell opened this issue Jul 27, 2017 · 18 comments

Comments

@edalzell
Copy link

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.

@anthubbard
Copy link

anthubbard commented Jul 27, 2017

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).

@lukeagsmith
Copy link

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.

@dannyuk1982
Copy link

👍 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

@jasonvarga
Copy link
Member

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.

@edalzell
Copy link
Author

@jasonvarga there's two options:

  1. the package you use has an option to enter the max file size
  2. on the server side, don't generate image thumbnails in the asset browser

Or both.

@anthubbard
Copy link

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?)

@dannyuk1982
Copy link

dannyuk1982 commented Jul 27, 2017

getimagesize doesn't need GD or Imagemagick etc. AFAIK it doesn't need to try to resize the image in order to get the size.

Can the size just be checked and if it's over X then a thumb is not generated?

@sebszocinski
Copy link

haven't tested this but it looks interesting?
https://github.com/rossturner/HTML5-ImageUploader

@dannyuk1982
Copy link

@Rockethouse looks perfect

@jasonvarga
Copy link
Member

So in 2.6.7, the memory issue should be solved, which is the root of this issue.

Large images seem to cause Statamic issues, including running out of memory

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

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.

If you're worried about a giant repo as per @anthubbard 's comment:

version control everything when clients upload 2gb of photos in 12 months on a tiny website

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.

❤️

@anthubbard
Copy link

anthubbard commented Aug 30, 2017

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:

Keep the original image: true

When uploading - then we can choose to keep it or discard it if we want?

Ant

@jasonvarga
Copy link
Member

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.

@anthubbard
Copy link

Hey this issue isn't with disk space which is cheap - it's with 2 problems:

  1. GIT limits on large files - both Github and Bitbucket have a max repo size limit of 1GB. I thought that would never happen but now have 15 client website repo's that are 900mb+ because of stupid large photos and over a 5 year lifespan its easy to get that up there. So now I have to manually go through and resize the images, start a new repo and replace with the resized images then replace the repo on the server with the new one etc etc. I don't want to have to do this.

  2. I have had heaps of issue with adding GIT commits that are bigger than about 250mb - it times out and won't push or pull the commits. It's fine in smaller chunks but again this is frustrating.

Thanks for reopening.

If I could gitignore files over a certain size I could use that but it doesn't exist.

Ant

@lukeagsmith
Copy link

If you have have an image manipulation set up, I quite like the idea of having a keep_original flag that defaults to true so if desired you can dump the original after resizing it.

@dannyuk1982
Copy link

keep_original alongside some resize defaults would solve this. So you just make a preset which is say i.e. 2000px (would need to be a setting in assets.yaml) max, and have everything resized to that (doing nothing if it was under the size)

@michaelmannucci
Copy link

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.

Is this no longer a thing? I don't see anything in the docs about resizing images on upload.

@adevade
Copy link

adevade commented Apr 28, 2022

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 config/statamic/assets.php.

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? 🙂

@jasonvarga
Copy link
Member

Feel free to open a feature request for Statamic v3 at https://github.com/statamic/ideas .

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

8 participants