Skip to content
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

Image Resizer fails after upgrade to Craft 3.3.15 #55

Open
ryanmasuga opened this issue Nov 14, 2019 · 2 comments
Open

Image Resizer fails after upgrade to Craft 3.3.15 #55

ryanmasuga opened this issue Nov 14, 2019 · 2 comments

Comments

@ryanmasuga
Copy link

ryanmasuga commented Nov 14, 2019

Description

We've been using Imager Resizer on a site for a long time and it has always worked fine. We recently updated this site to Craft 3.3.15 a realized Imager Resizer simply doesn't appear to be working any longer. The client was somehow able to upload 3000 pixel high images to a directory that was set to resize to 1200 max height. So we looked at the logs and saw errors.

Also, selecting images in the Assets list now and trying to resize them now after the initial upload does nothing.

Our Control Panel log looks like this now (note all those images were being uploaded to the same directory, yet there are two different errors, and that volume has definitely worked before):

sudden_errors

And from the log file, we're seeing this slightly more detailed error (lightly edited to anonymize):

2019-11-14 11:33:49 [-][-][-][error][craft\queue\QueueLogBehavior::afterError]  [10161] Resizing images (attempt: 1) - Error (time: 0.034s): Argument 4 passed to verbb\imageresizer\services\Resize::resize() must be of the type integer or null, string given, called in /vendor/verbb/image-resizer/src/jobs/ImageResize.php on line 68
2019-11-14 11:33:49 [-][-][-][error][TypeError] TypeError: Argument 4 passed to verbb\imageresizer\services\Resize::resize() must be of the type integer or null, string given, called in /vendor/verbb/image-resizer/src/jobs/ImageResize.php on line 68 and defined in /vendor/verbb/image-resizer/src/services/Resize.php:31
Stack trace:
#0 /vendor/verbb/image-resizer/src/jobs/ImageResize.php(68): verbb\imageresizer\services\Resize->resize(Object(craft\elements\Asset), 'clientimage_0027.j...', '/home/client/...', '', '1200', 'hMSrH')
#1 /vendor/yiisoft/yii2-queue/src/Queue.php(214): verbb\imageresizer\jobs\ImageResize->execute(Object(craft\queue\Queue))
...

(we can share a full stack trace if needed)

Other than updating the CMS from 3.0.41.1 to 3.3.15, no other changes were made to asset sources or settings.

Steps to reproduce

  1. Have setting to restrict upload height on upload.
  2. Upload large image, and image does not get resized.

Additional info

  • Plugin version: 2.0.6
  • Craft version: 3.3.15
@ryanmasuga
Copy link
Author

I updated asset indexes and that seemed to correct the display of the image sizes in the asset entries lists. I still can't seem to bulk resize selected assets from the lists. The CP error I get is "Resizing would result in a larger file" even though the measurements I'm entering are smaller than the file I'm trying to resize.

Can confirm that resizing on upload is not happening either. Uploaded image 3056 pixels tall, and it did not get resized to 1200.

1) Here's the test upload:
01-test-upload

2) The error in the CP log:
02-larger-file

3) And the setting for that (parent) volume: Note that these images are all being uploaded to subdirectories of a directory called "Read" - My test image was being uploaded to /read/foo for example.
03-settings

@engram-design
Copy link
Member

Sorry for the delay! So the warning about a larger file, is referring to the file size, not the dimensional size. I better adjust that message to reflect that. This can often happen if the image is already compressed, or if there's no good compression libraries available for GD/Imagemagik to use. The whole point of the plugin is to lower the file size used by assets - so it would be counter-productive to allow this!

In your case, I'm not surprised that resizing a 1mb file might produce a larger one. Without testing the actual asset, its hard to tell if this is correct.

I'll look into the path issue, that certainly seems to be new.

And as for your error Argument 4 passed to..., it seems like the plugin is having issues getting the image width (the original width), for some reason. I wonder if re-indexing your assets fixed this?

What type is your volume - local, S3, or other?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants