Cms: Make it possible to restrict Assets fields to specific extensions/MIME types

[andris-sevcenko]

Description

In addition to the list of file kinds, Assets fields should also have some way of specifying additional file extensions and/or MIME types.

[MattWilcox]

This would be really useful as we have a number of clients that like to upload large photos in PNG format. A dozen megs per image in entirely the wrong format eating loads of disk space and processor cycles.

[narration-sd]

Or would it be better just to have ability for a mandatory conversion to a tamer format -- Jpeg, Webp, etc.?

[MattWilcox]

No; I don't want the source files being megabytes bigger than needed either - space is expensive once you start getting a gig of pointless files on your server. We can already specify the transform output type, that's not a problem.

[narration-sd]

png->jpg conversion on upload should make the base file smaller, no?

Similarly control could be added for the pixel dimensions for the upload result, for more help.

[MattWilcox]

Ah, I see what you meant now. Craft at the moment just stores the source image untouched. You're proposing that under certain conditions the source image is modified, either by re-sizing and/or re-encoding into another format? That will work in some cases, but not in others - if the user uploads a 20Mb PNG photo (it's happened more than once) then the server isn't able to perform any transform on it without dying - so the "source" image will never be successfully re-encoded in the first place.

[MattWilcox]

We were bitten by this yet again today and it's taken hours to fix as we moved from a server with ridiculously high limits to a proper server with smaller limits; suddenly hundreds of images could no longer be transformed, and thus the live server's site appeared broken.

There aren't any decent image editors that will walk through a directory structure and only down-sample images over a given target dimension, or convert truly massive PNGs to smaller dimensioned JPGs. Photoshop just up-samples as well as down-sample.

[narration-sd]

Hey, Matt. I found you'd done something interesting on images yourself, http://adaptive-images.com/, so you should certainly understand many issues here.

• this calculator gives a quick idea of PHP server memory allowance required (above Craft's own) for conversion -- it looks like circa 110MB plus for your 20MB png to a reasonable jpg --
  http://www.dotsamazing.com/en/labs/phpmemorylimit . It seems 256MB should be doable even for a small server, which would cover this?

• I'm not sure what you're saying about Photoshop -- it's certainly capable of batch downsizing, as would be even venerable Irfanview, according to the intertubes.

• however, much better if Craft handled this itself, which is what I was suggesting -- so there would be no mega 'source image' stored except as a temporary until it converted.

• keeping things sprightly probably means moving the source conversion to a background task, and this is not the most robust arrangement of Craft, if improved in Craft 3, but may be able to work ok, always given you provide the adequate PHP memory limit. Anyway, it seem s worth a try, and @andris no doubt has a lot of experience already with the ins and outs of it so I will sign off here...

Best fortune, and hoping to have contributed by airing this out a little, anyway. It would be great to have a nice, robust solution, for everyone.

Clive

[MattWilcox]

The memory footprint on the server depends on the resolution not the file size. We've had clients regularly uploading in the area of 10,000 x 8,000 pixel images; it blows out the server. And remember that 256Mb (actually 400+ for these resolutions) seems ok until you realise that server is also serving requests at the same time, or has a batch of images to do not just the one.

I'd much much rather be able to set Craft to simply reject images larger than a given dimension and tell the user to upload something more reasonable. The fact that some of these are PNGs or TIFFs doesn't effect the memory footprint but does make a massive impact on storage space. These are not efficient filetypes for photographic images.

[narration-sd]

Hmm. Sounds like a configurable compromise situation then -- do appreciate about the newer cameras, other ways huge pixel counts can be presented.
me
As a pair of features, then:

• your maximum-dimensions limit, units to be determined, and according to what @andris-sevcenko finds easy/doable, but let's say megapixels, as people are used to camera ratings, and it avoids asking dimensions. If this limit is surpassed, the uploading person gets an alert instead of the upload, which suggests not only the MP to come in under, but example dimensions for the pic that would succeed. I guess those can be in pixels, and probably calculated by the aspect ratio of the submission -- think it's available from headers, which said Andris has recently done other neat things with?

• I'd still think an automatic resize for more server-reasonable pixel dimensions would be a very nice thing to have, because if you can do it automatically, a lot less is required of the submitting person. A similar MP limit could be used, so now you would have two simple parameters to control the situation.

It feels this should work out well, the normal contributors just doing their uploads while server factors are under control -- and the advantage that untransformed originals won't be sent out in their huge form either, definitely a speed advantage, and particularly so for tablets and phones.

Meanwhile the more likely offenders, with their super-cameras, get precise instructions how to succeed by using their likely companion tools to downsize -- and xo they also get the control they would like in doing this, such as the sharpening which helps perceived quality on downsizing.

Hoping we might be zeroing in, Matt, and being of some help then in having talked about it...cheers

[olets]

Another use case: this would make it possible to require one mp4 and one webm for a <video>-related field

[brandonkelly]

@olets That’s currently possible by defining custom file kinds, using the extraFileKinds config setting (albeit using file extensions rather than MIME types).

[olets]

Oh cool I'll have to try that out 🙌

[Friksel]

@brandonkelly Nice solution! Works great and easy to apply. Love it

[darylknight]

Dragging this up from the past and adding my thoughts too. Normally the file kind has been enough for just limiting to images, but I'm finding increasingly that I want to limit some asset fields to "SVG only", for sites with a lot of custom illustration work. The crops in those fields aren't designed for photographs, so I'd like to be able to limit the client to only upload JPGs/PNGs to some fields, and only SVGs to others.

[brandonkelly]

@darylknight In the meantime you should be able to accomplish that using the extraFileKinds config setting.

'extraFileKinds' => [
    'svg' => [
        'label' => 'SVG',
        'extensions' => ['svg']
    ],
],

[darylknight]

This is brilliant, thank you. Just what I need for the illustration fields.