v2-hub icon indicating copy to clipboard operation
v2-hub copied to clipboard

FR: Allow images to be resized on upload

Open edalzell opened this issue 7 years ago • 18 comments

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.

edalzell avatar Jul 27 '17 04:07 edalzell

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

anthubbard avatar Jul 27 '17 05:07 anthubbard

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.

lukeagsmith avatar Jul 27 '17 09:07 lukeagsmith

👍 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

dannyuk1982 avatar Jul 27 '17 13:07 dannyuk1982

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 avatar Jul 27 '17 15:07 jasonvarga

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

edalzell avatar Jul 27 '17 15:07 edalzell

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

anthubbard avatar Jul 27 '17 16:07 anthubbard

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?

dannyuk1982 avatar Jul 27 '17 16:07 dannyuk1982

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

sebszocinski avatar Jul 28 '17 06:07 sebszocinski

@rockethouse looks perfect

dannyuk1982 avatar Jul 28 '17 09:07 dannyuk1982

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.

❤️

jasonvarga avatar Aug 28 '17 19:08 jasonvarga

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

anthubbard avatar Aug 30 '17 00:08 anthubbard

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.

jasonvarga avatar Aug 30 '17 01:08 jasonvarga

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

anthubbard avatar Aug 30 '17 01:08 anthubbard

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.

lukeagsmith avatar Aug 30 '17 06:08 lukeagsmith

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)

dannyuk1982 avatar Aug 30 '17 08:08 dannyuk1982

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.

michaelmannucci avatar Apr 23 '22 03:04 michaelmannucci

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

adevade avatar Apr 28 '22 08:04 adevade

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

jasonvarga avatar Apr 29 '22 06:04 jasonvarga