$file
class. Therefore the $file->move_file()
method decides that the image is still too large, aborts and throws an error.Just a thought, but if you're sure you've resized it to the correct/allowed dimensions, you could overwrite the 'allowed dimensions' from the
upload
class, to unlimited or original image size +1px or something like that?Correct me if I'm wrong here but could not the extension have it's own settings for what it will be resized to? Setting the dimensions in the core to a high amount and only used as a limit on the uploaded file size, yes?Ger wrote: ↑Fri Feb 02, 2018 1:55 pm I've tried to wrap my head around this for an extension, but the upload process is bugging me. Basically the only point in the entire process to hook into is core.avatar_driver_upload_move_file_before. I'm capable of resizing the file, but I cannot overwrite the protected width and height properties of the$file
class. Therefore the$file->move_file()
method decides that the image is still too large, aborts and throws an error.
Sorry guys, guess you'll have to wait for this to get into the core.
That was the easiest option, but the dimensions are of course in the config and there is no sane event to hook into before the avatar processing is done. Actually, I see onlyposey wrote: ↑Fri Feb 02, 2018 4:01 pm Just a thought, but if you're sure you've resized it to the correct/allowed dimensions, you could overwrite the 'allowed dimensions' from theupload
class, to unlimited or original image size +1px or something like that?
Not sure if it's possible, but just an idea.
core.common
but that's the most ugly way to do this. @Thecoalmans approach seems more logical:This can indeed work: setting the config values to idiot amounts to make sure every image is processed and then overwrite the whole thing using extension settings (either hard coded orthecoalman wrote: ↑Fri Feb 02, 2018 8:46 pm Correct me if I'm wrong here but could not the extension have it's own settings for what it will be resized to? Setting the dimensions in the core to a high amount and only used as a limit on the uploaded file size, yes?
I implemented this with a couple of lines editing core files, it's easy to do because I'm using imagemagick and that is basically how it works on my forum. In my case the resized dimensions are hard coded.
ger_avatarresize_max_height
and such).phpbb\files\filespec::width
phpbb\files\filespec::height
where public instead of protected it should be a very easy extension. Or create a setter function for them, like
Code: Select all
public function dimensions_set($width, $height)
{
if (is_int($width) && is_int($height))
{
if (!empty($width))
{
$this->width = $width;
}
if (!empty($height))
{
$this->height = $height;
}
}
return $this;
}
I don't think it's hacky, the admin may want to set a limit for upload. Those images are converted server side as I'm sure you are aware. I don't know if it's improved but the GD library will consume a lot of RAM for conversion and can easily exceed the RAM limits in the past. If I recall correctly am image with a width of about 5000px was pushing the limits for a 256MB value set for the max RAM a script could consume. If I understand correctly GD converts to uncompressed before conversion hence the reason it will consume so much RAM. Hopefully future version of phpBB utilize plupload for this.
Perhaps I expressed myself wrong. English is not my native language so this happens sometimesthecoalman wrote: ↑Mon Feb 05, 2018 2:59 pmI don't think it's hacky, the admin may want to set a limit for upload. Those images are converted server side as I'm sure you are aware. I don't know if it's improved but the GD library will consume a lot of RAM for conversion and can easily exceed the RAM limits in the past. If I recall correctly am image with a width of about 5000px was pushing the limits for a 256MB value set for the max RAM a script could consume. If I understand correctly GD converts to uncompressed before conversion hence the reason it will consume so much RAM. Hopefully future version of phpBB utilize plupload for this.
As far as hardcoding the resized value that works for me but I'm sure most people will want to set their own value.
create_thumbnail()
function for attachments also uses imagemagick if available. But of course: you make edits to the core file so any extension doing that would be instantly denied.core.avatar_driver_upload_move_file_before
should also pass the $file
object as var. I've done so locally and with it, I'm perfectly capable to resize any given avatar within the given KB range and store it as desired.I've looked at it, but quite frankly I don't have a complete understanding of how plupload actually works or how I should implement it in the avatar upload functionality. I do have quite some experience with resizing on the PHP side of things so it's easier for me to take that approach.thecoalman wrote: ↑Mon Feb 05, 2018 4:26 pm Ideally you have plupload handle it, have you explored that option?