ログに記録されたエラーメッセージを送信するようにサイトを構成しましたが、sorl-thumbnail 12.4.1にアップグレードしてから、次のエラーメッセージが表示されます。
missing file_ argument in get_thumbnail()
このエラーを発行するコード行は次のとおりです。
この行を書いたのは私で、例外からログに記録されたエラーに変更したことがわかります:0375ffe9b66e571bfeb7581fb47174f50b47468f
私はここで@mariocesarのコメントに基づいてhttps :
raise ValueError('missing file_ argument in get_thumbnail()')
については、おそらくDEBUG = Falseでサイレントにする必要がありますが、エラーは維持します。 これは一般的な問題です。
12.4.1にもアップグレードしたばかりで、ログがいっぱいになるこのエラーが発生し始めています。
これは#472に戻ります。 sorl-thumbnailの古い動作は、実際にはファイルがないファイルフィールドを渡しても問題がなく、空の文字列に解決されるというものでした。 get_thumbnail
はNoneを返すため、templatetagは代わりに空の代替をレンダリングします。
これは明らかに最新リリースで変更されました!
意図された動作は何ですか? すべてのサムネイル呼び出しを{% if object.my_image_field %}
ラップすることになっている場合は、コードを更新するだけです。 これがリグレッションの場合-これを修正するためのPRを作成するつもりですが、最初に修正が必要なものかどうかを知りたいです。
PyPiでリリースされた古いバージョン12.4a1には、あなたが説明した動作、@ tomkinsがあります。 これは本来意図された動作だったと思います。 これは、ドキュメントが言っていることであり、7年間言っています:
empty
機能を使用すると、ソースが空の値または無効な画像ソースに解決されたときにempty
セクションがレンダリングされます。これは、サムネイルが未定義になったときにレンダリングされると考えることができます。
PyPIでのそのリリース以降、 @ mariocesarはこのfile_
引数が欠落して例外がスローされました。
テストに合格するために、このプルリクエスト#493とこのリベースされたコミット0375ffe9でこのコードを変更し、コメントhttps:// githubの@mariocesarのアドバイスに基づいて、例外をログに記録されたエラーに.com / jazzband / sorl-thumbnail / pull / 493#issuecomment -299302392。
空の文字列またはNone値が渡されたときにget_template
呼び出さないようにテンプレートタグを変更する必要があるかもしれません。そうすれば、 get_template
の関数本体にエラーをログに記録する(または例外)。 {% if object.my_image_field %}
ラッピングを含めるために、すべてのテンプレートを変更する必要は絶対にありません。
PyPIでリリースされるまで、これを開いたままにしておきましょう。
これがいつpypiでリリースされるかについてのアイデアはありますか? 12.4.1でもエラーが発生する
+1
同じエラーが発生しました。エラーはsentry.io
ログファイルで報告されます。
やあ。 PyPIで利用可能なアップストリームバージョンのこの修正に更新はありますか? 私のプロジェクトは意図したとおりに機能していますが、テストでPOSTリクエストを検証するために作成された一時ファイルを使用しているときに、このエラーを偶然発見しました。 それを回避するための回避策はありますか?
@ sebastian-code PyPIで新しいバージョンがリリースされるのを待っている間、次のようにGitHubからこれをインストールできます。
$ pip install -e git+https://github.com/jazzband/sorl-thumbnail.git@b6358d234d7de3927a2666a2a5ab3d7870c0e1d3#egg=sorl_thumbnail
b6358d234d7de3927a2666a2a5ab3d7870c0e1d3
を、使用するコミットのコミットハッシュに置き換えることができます。
バグがリリースされるまで、バグを開いたままにしておくことに価値はありません。
@timgrahamそうだと思います。 GitHubコミッターが、対応するバグ修正がPyPIでリリースされるまで問題を開いたままにしておくと、私はそれを好みます。 リリースされたプロジェクトでバグに遭遇すると、そのバグレポートを検索しようとすることがよくあります。未解決の問題が見つからない場合は、新しい問題を提出します。 古いクローズされた問題を見つけたとしても、リグレッションを想定して新しい問題を提出します。 バグ修正が実際にリリースされたときにのみバグレポートが閉じられる場合、この問題は回避されます。
私は@Flimmに同意します。開発者が自分のプロジェクトステータスを追跡するのにも役立つと思います@timgraham
最も参考になるコメント
@timgrahamそうだと思います。 GitHubコミッターが、対応するバグ修正がPyPIでリリースされるまで問題を開いたままにしておくと、私はそれを好みます。 リリースされたプロジェクトでバグに遭遇すると、そのバグレポートを検索しようとすることがよくあります。未解決の問題が見つからない場合は、新しい問題を提出します。 古いクローズされた問題を見つけたとしても、リグレッションを想定して新しい問題を提出します。 バグ修正が実際にリリースされたときにのみバグレポートが閉じられる場合、この問題は回避されます。