Date: Tue, 23 Oct 2012 02:33:10 -0700 (PDT)
From: Martimiz <marti...@gmail.com>
To: silverstripe-dev@googlegroups.com
Message-Id: <0b4c56c7-d9cc-43ec-9a15-260f6669d63e@googlegroups.com>
In-Reply-To: <50856B4F.8040801@kristoferitsch.name>
References: <29f387c2-01b4-4416-b72e-b360ce2094f7@googlegroups.com>
 <50856B4F.8040801@kristoferitsch.name>
Subject: Re: [silverstripe-dev] Block high compression/large dimension
 images, that crash the system on resize
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_2001_11153734.1350984790882"

------=_Part_2001_11153734.1350984790882
Content-Type: multipart/alternative; 
	boundary="----=_Part_2002_25757888.1350984790882"

------=_Part_2002_25757888.1350984790882
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Thanks very much,  Roman, Jacob for your input :-)

> [...]best to allow configuration of a max. pixel sum for uploaded images. 
> The default setting should be something sensible that works well with 
> the SS3 system requirements (48mb memory). 

I would agree with that - especially for an initial setup

> [...]dynamically creating a "Not enough memory" image and using this 
> instead would be a possible solution...

I very much like the idea, as we'd no longer need other checks/error 
messages. It could also protect against other large files slipping in by 
FTP, give the user fair warning at all time, allow uploading images for 
download purposes only (archives are always better, but not every user will 
realize that).  And it would all be  kept within GD class, like Jacob is 
working towards. 

> [...] developers could implement their own handler and use ImageMagick 
> instead or come up with other forms of dealing with these images

Question: would we use a validation-function in GD, extended to accomodate 
a decorator, or some sort of Validator class that can be subclassed? 

The initial setup could very well use an existing image in assets, and a 
simple check against max file size as well as dimensions. Custom handlers 
could use other images or GD to generate an image with some text 
(translatable) and custom checks could be implemented - like the one Jacob 
suggests.

What do you think?

Martine



 
  

------=_Part_2002_25757888.1350984790882
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

Thanks very much,&nbsp; Roman, Jacob for your input :-)<br><br>&gt; [...]best to allow configuration of a
      max. pixel sum for uploaded images. <br>&gt; The default setting should be
      something sensible that works well with <br>&gt; the SS3 system
      requirements (48mb memory). <br><br>I would agree with that - especially for an initial setup<br><br>&gt; [...]dynamically creating a
      "Not enough memory" image and using this <br>&gt; instead would be a
      possible solution...<br><br>I very much like the idea, as we'd no longer need other checks/error messages. It could also protect against other large files slipping in by FTP, give the user fair warning at all time, allow uploading images for download purposes only (archives are always better, but not every user will realize that).&nbsp; And it would all be&nbsp; kept within GD class, like Jacob is working towards. <br><br>&gt; [...] developers could implement their own handler and use
      ImageMagick <br>&gt; instead or come up with other forms of dealing with
      these images<br><br>Question: would we use a validation-function in GD, extended to accomodate a decorator, or some sort of Validator class that can be subclassed? <br><br>The initial setup could very well use an existing image in assets, and a simple check against max file size as well as dimensions. Custom handlers could use other images or GD to generate an image with some text (translatable) and custom checks could be implemented - like the one Jacob suggests.<br><br>What do you think?<br><br>Martine<br><br><br><br>&nbsp;<br>&nbsp; <br>
------=_Part_2002_25757888.1350984790882--

------=_Part_2001_11153734.1350984790882--