Sorl-thumbnail: Fehler "fehlendes file_argument in get_thumbnail" in Protokollen und E-Mails

Ich habe auch gerade auf 12.4.1 aktualisiert, und ich bekomme diesen Fehler beim Füllen unserer Protokolle.

Dies geht zurück auf #472. Das alte Verhalten von sorl-thumbnail war, dass es in Ordnung war, ein Dateifeld zu übergeben, das eigentlich keine Datei hatte, die in einen leeren String aufgelöst wurde. get_thumbnail würde None zurückgeben, sodass das templatetag stattdessen die leere Alternative rendern würde.

Dies hat sich mit der neuesten Version offensichtlich geändert!

Was ist das beabsichtigte Verhalten? Wenn wir alle unsere Thumbnail-Aufrufe mit {% if object.my_image_field %} umschließen sollen, dann aktualisiere ich einfach meinen Code. Wenn dies eine Regression ist, bin ich bereit, eine PR zu erstellen, um dies zu beheben, aber ich würde gerne wissen, ob es etwas ist, das zuerst behoben werden muss.

Die alte Version, die auf PyPi veröffentlicht wurde, 12.4a1 hat das von Ihnen beschriebene Verhalten @tomkins. Ich denke, das war das ursprünglich beabsichtigte Verhalten. Das sagen die Docs und sagen es seit sieben Jahren:

Mit der Funktion empty wird der Abschnitt empty gerendert, wenn die Quelle in einen leeren Wert oder eine ungültige Bildquelle aufgelöst wird. Sie können es sich als Rendering vorstellen, wenn die Miniaturansicht nicht definiert wird.

Seit dieser Veröffentlichung auf PyPI hat @mariocesar diesen file_ Argument eine Ausnahme auslöste.

Um die Tests zu bestehen, habe ich dann diesen Code in diesem Pull-Request #493 und in diesem rebased Commit 0375ffe9 geändert und die Ausnahme in einen protokollierten Fehler verwandelt, basierend auf dem Rat von @mariocesar im Kommentar https://github .com/jazzband/sorl-thumbnail/pull/493#issuecomment -299302392 .

Vielleicht sollten wir die Template - Tag ändern nicht anrufen get_template , wenn eine leere Zeichenfolge oder einen Keiner Wert übergeben, und auf diese Weise können wir die Funktion Körper halten get_template Anmeldung einen Fehler (oder werfen ein Ausnahme). Ich möchte definitiv nicht, dass die Leute alle ihre Vorlagen so ändern müssen, dass sie {% if object.my_image_field %} Wrapping enthalten!

Lassen Sie uns dies offen halten, bis es auf PyPI veröffentlicht wird.

Haben Sie eine Idee, wann dies auf pypi veröffentlicht wird? Immer noch die Fehler mit 12.4.1

+1

Habe gerade den gleichen Fehler bekommen, der Fehler wird mit meiner sentry.io Protokolldatei gemeldet.

Hi. Gibt es Updates in diesem Fix für die verfügbare Upstream-Version in PyPI? Mein Projekt funktioniert wie beabsichtigt, aber ich entdecke diesen Fehler zufällig, wenn ich eine temporäre Datei verwende, die erstellt wurde, um eine POST-Anfrage mit meinen Tests zu validieren. Gibt es eine Arbeit drum herum?

@sebastian-code Während wir auf die Veröffentlichung einer neuen Version auf PyPI warten, können Sie diese wie folgt von GitHub installieren:

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

Sie können b6358d234d7de3927a2666a2a5ab3d7870c0e1d3 durch den Commit-Hash des Commits ersetzen, den Sie verwenden möchten.

Siehe https://github.com/jazzband/sorl-thumbnail/issues/546

Ich sehe keinen Wert darin, Bugs offen zu halten, bis sie veröffentlicht werden.

@timgraham Ich glaube, das tue ich. Ich bevorzuge es, wenn GitHub-Committer Probleme offen halten, bis ihre entsprechenden Bugfixes auf PyPI veröffentlicht werden. Wenn ich in einem veröffentlichten Projekt auf einen Fehler stoße, versuche ich oft, nach seinem Fehlerbericht zu suchen, und wenn ich dann kein offenes Problem finden kann, reiche ich ein neues ein. Selbst wenn ich das alte abgeschlossene Problem finde, reiche ich ein neues ein, unter der Annahme einer Regression. Wenn Fehlerberichte erst geschlossen werden, wenn die Fehlerbehebungen tatsächlich veröffentlicht werden, wird dieses Problem vermieden.

Ich stimme @Flimm zu. Ich denke, es hilft Entwicklern auch, den eigenen Projektstatus zu verfolgen @timgraham