Warum schlägt die API beim Erstellen von Thumbnails oft fehl, obwohl ausreichend große Bilder heruntergeladen werden?
Beispiel: Wenn Sie dies in einen Eröffnungsbeitrag einfügen…
Dieses Onebox lädt ein ausreichend großes Bild mit den Abmessungen 690 x 465 herunter:
Trotzdem wird für das Thema kein Thumbnail erstellt.
Es hängt nicht von der Größe des Bildes ab. Im Allgemeinen übernehmen wir keine Bilder aus Oneboxes, da sie in vielen Fällen nicht als Thumbnails geeignet sind. Beispielsweise sehen wir auf Meta häufig GitHub-Repository-Links wie
Niemand möchte, dass mein Gesicht vergrößert und zum Themen-Thumbnail gemacht wird 
Nun, das ist sehr spezifisch für Meta. Wir haben in unserer Community keine GitHub-Links. Es geht hier um News, und Onebox-Bilder sollten verwendet werden. Dies schränkt die Thumbnails stark ein, nur wegen dieses „Gesicht“-Problems bei Meta. Gibt es eine Möglichkeit, dies zu ändern und Bilder aus Oneboxes hinzuzufügen? Ich vermute, vielen Communities sind die GitHub-Gesichter egal.
Ich bin hier definitiv offen für Verbesserungen. Ich weiß, dass @merefield ebenfalls an dieser Logik interessiert ist. Die Änderung müsste im Core erfolgen und nicht in einem Plugin, daher werde ich dies in ein eigenes Thema auslagern.
Hier ist die bestehende Logik:
Vielleicht könnten wir bestimmten Onebox-Arten (z. B. GitHub) eine .no-thumbnail-Klasse hinzufügen und Discourse dann anweisen, nur diese zu ignorieren, während andere Onebox-Bilder erhalten bleiben.
Ich werde das Label pr-welcome hinzufügen, aber stelle sicher, dass du in diesem Thema einen Plan darlegst, bevor du substantielle Arbeiten beginnst.
Das wäre großartig. 90 % unserer Themen erhalten derzeit keine Vorschaubilder, obwohl sie dies könnten. Und wie bereits erwähnt, ist dieses GitHub-Problem ein sehr spezifischer Randfall für Entwickler-Communities. Der weitaus größte Teil von uns erhält keine Vorschaubilder für Themen, die definitiv welche haben könnten, und zwar aufgrund genau dieses Problems.
Ich stimme dem voll zu!!! Für den Anwendungsfall eines News-Aggregators oder jeder anderen Art von Seite mit vielen Weiterveröffentlichungen ist das Fehlen relevanter Vorschaubilder ein echtes Problem.
Wenn ihr das nicht bald integrieren, habt ihr Ideen, wie man das auf meiner selbst gehosteten Distribution umsetzen kann?
Ja, das steht derzeit nicht zur Debatte, da „Gesichter
Das OP-Beispiel wird für Vorschauen der Themenliste korrekt dargestellt, da ich im Plugin breitere Kriterien verwende:
def extract_images_for_post
# Alle Bilder mit einem src-Attribut
@doc.css("img[src]") -
# Minus Emojis
@doc.css("img.emoji") -
# Minus Bilder in Zitaten
@doc.css(".quote img") -
# Minus Site-Icons von Onebox
@doc.css("img.site-icon") -
# Minus Avatare von Onebox
@doc.css("img.onebox-avatar") # Breitere Kriterien als im Discourse Core
end
Ja, danke @merefield, aber wir verwenden nur @david’s Theme-Komponente, nicht das TLP TC. Falls wir keine Fortschritte erzielen oder keine Option vom @team zu diesem Thema erhalten, werde ich wahrscheinlich deine Auswertung nutzen, um den Kern zu patchen.
Das obige Rendering stammt vom TLP TC, aber ja, ich verwende ein Backend-Plugin (das Theme ‘side car’), um Ruby zu modifizieren :). https://github.com/merefield/discourse-topic-previews/tree/theme_sidecar Ich schätze, dass dies bei einer gehosteten Version möglicherweise keine Option ist.
Das steht absolut auf der Tagesordnung, deshalb ist es mit pr-welcome gekennzeichnet 
Schau dir diesen Beitrag als Ausgangspunkt für die Umsetzung an.
@merefield Könntest du bitte den PR erstellen? Leider bin ich komplett neu in Ruby. Oder wie läuft der Prozess für einen PR ab?
@david Ich wäre definitiv sehr erfreut, diese Überschreibung aus den Plugins entfernen zu können, und stimme zu, dass eine Kernlösung am besten wäre.
@Terrapop hier sind die Contributing to Discourse development
Ich wäre gerne direkter bei der Sache, aber gerade mit Kundenarbeit voll ausgelastet.
Verstanden. Ich habe derzeit nur eine einfache Docker-Entwicklungsumgebung für die Entwicklung einiger einfacher Plugins und Kern-Patches. Ich warte darauf, dass sich jemand dies ansieht, und werde in der Zwischenzeit wahrscheinlich über Ihre Evaluation einen Patch erstellen.
Eine ordentliche Lösung hier ist kein immaterielles Projekt, da Sie Testfälle anpassen und an beiden Komponenten (Discourse und Discourse One-Box) arbeiten müssen. Aber es lohnt sich definitiv!
Ruby ist übrigens nichts, wovor man Angst haben müsste
Ja, aber das liegt leider definitiv außerhalb meines aktuellen Aufgabengebiets und meiner Fähigkeiten.
Als Workaround kopiere und füge ich das Bild oft manuell in einen Whisper ein und wähle dann die Miniaturansicht daraus aus.
Eine automatische Lösung wäre schöner, vielleicht mit einer Konfigurationsoption, um Domains anzugeben, für die keine Miniaturansichten aus One-Boxen erstellt werden sollen (z. B. um den GitHub-Fall abzudecken).
Zustimmung. Wir haben @merefields Snippet verwendet, um das Core-System mit einem Mini-Plugin zu überschreiben. Es sollte jedoch für das Core-Team leicht sein, eine Out-of-the-Box-Lösung zu entwickeln. Nur weil sich einige scheuen, ihre GitHub-Profile zu zeigen, diese Funktion nicht anzubieten, ist einfach nur faul.
Ich habe gerade FEATURE: Allow onebox images to be used as topic thumbnails (#12050) · discourse/discourse@b770c30 · GitHub gemergt, was es ermöglicht, Onebox-Bilder als Themen-Miniaturansichten auszuwählen. Für die GitHub-Onebox gibt es eine spezifische Ausnahme, und wir können bei Bedarf weitere hinzufügen.
(cc @Terrapop @merefield)