New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FR: Allow images to be resized on upload #1528

Open
edalzell opened this Issue Jul 27, 2017 · 15 comments

Comments

Projects
None yet
6 participants
@edalzell

edalzell commented Jul 27, 2017

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

This comment has been minimized.

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

This comment has been minimized.

lukeagsmith commented Jul 27, 2017

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

This comment has been minimized.

dannyuk1982 commented Jul 27, 2017

👍 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

This comment has been minimized.

Member

jasonvarga commented Jul 27, 2017

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

This comment has been minimized.

edalzell commented Jul 27, 2017

@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

This comment has been minimized.

anthubbard commented Jul 27, 2017

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

This comment has been minimized.

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

This comment has been minimized.

sebszocinski commented Jul 28, 2017

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

@dannyuk1982

This comment has been minimized.

dannyuk1982 commented Jul 28, 2017

@Rockethouse looks perfect

@jasonvarga

This comment has been minimized.

Member

jasonvarga commented Aug 28, 2017

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 jasonvarga closed this Aug 28, 2017

@anthubbard

This comment has been minimized.

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

This comment has been minimized.

Member

jasonvarga commented Aug 30, 2017

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

This comment has been minimized.

anthubbard commented Aug 30, 2017

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

This comment has been minimized.

lukeagsmith commented Aug 30, 2017

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

This comment has been minimized.

dannyuk1982 commented Aug 30, 2017

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment