"missing file_ argument in get_thumbnail" error in logs and email

[Flimm]

I have configured my site to send my logged error messages, and I have been getting these error messages ever since upgrading to sorl-thumbnail 12.4.1:

missing file_ argument in get_thumbnail()

Here's the line of code emitting this error:

sorl-thumbnail/sorl/thumbnail/base.py

Line 83 in a99797f

logger.error('missing file_ argument in get_thumbnail()')

I see that I was the one who wrote this line, changing it from an exception to a logged error: 0375ffe

I did so based on @mariocesar's comment here: #493 (comment)

There is a thing about raise ValueError('missing file_ argument in get_thumbnail()') we need to silent that in DEBUG=False probably, but maintain the error. It's a common problem.

[tomkins]

Just upgraded to 12.4.1 as well, and I'm starting to get this error filling up our logs.

This goes back to #472. The old behaviour of sorl-thumbnail was that it was okay to pass a file field which didn't actually have a file, which resolved to an empty string. get_thumbnail would return None, so the templatetag would render the empty alternative instead.

This has obviously changed with the latest release!

What's the intended behaviour? If we're supposed to wrap all our thumbnail calls with {% if object.my_image_field %} - then I'll just update my code. If this is a regression - I'm willing to create a PR to fix this, but I'd like to know if it's something which needs fixing first.

[Flimm]

The old version released on PyPi, 12.4a1 does have the behaviour you describe, @tomkins. I think this was the originally intended behaviour. This is what the docs say and have been saying for seven years:

Using the empty feature, the empty section is rendered when the source is resolved to an empty value or an invalid image source, you can think of it as rendering when the thumbnail becomes undefined.

Since that release on PyPI, @mariocesar committed this 17748e5 , which caused a missing file_ argument to throw an exception.

In order to get the tests to pass, I then changed this code in this pull request #493 and in this rebased commit 0375ffe, turning the exception to a logged error, based on the advice of @mariocesar in the comment #493 (comment) .

Maybe we should change the template tag to not call get_template when passed an empty string or a None value, and that way, we can keep the function body of get_template logging an error (or throwing an exception). I definitely don't want people to have to modify all their templates to include {% if object.my_image_field %} wrapping!

[Flimm]

Let's keep this open until it's released on PyPI.

[odero]

Any idea on when this will be release on pypi? Still getting the errors with 12.4.1

[bartmika]

+1

Just got the same error, the error gets reported with my sentry.io log file.

[sebastian-code]

Hi. Is there any updates in this fix on the upstream available version in PyPI? My project is working as intended, but I discover this error by chance when using a temporary file created to validate a POST request with my tests. Is there a work around it?

[Flimm]

@sebastian-code While we're waiting for a new version to be released on PyPI, you can install this from GitHub, like this:

$ pip install -e git+https://github.com/jazzband/sorl-thumbnail.git@b6358d234d7de3927a2666a2a5ab3d7870c0e1d3#egg=sorl_thumbnail

You can replace b6358d234d7de3927a2666a2a5ab3d7870c0e1d3 with the commit hash of the commit you want to use.

See #546

[timgraham]

I don't see value in keeping bugs open until they're released.

[Flimm]

@timgraham I guess I do. I prefer it when GitHub committers keep issues open until their corresponding bug fixes are released on PyPI. When I come across a bug in a released project, I often try to search for its bug report, and then if I can't find an open issue, I file a new one. Even if I do find the old closed issue, I file a new one, assuming a regression. If bug reports are closed only when the bug fixes are actually released, this problem is avoided.

[sebastian-code]

I do agree with @Flimm I think it also helps developers to keep track of their own project status @timgraham