Wir starten ein Forum für unser Produkt, dessen externe Einbettungen bereits mit OneBox funktionieren, nachdem Iframes von uns zugelassen wurden.
Ein direkter Link zu einem Embed wird sauber in das Ergebnis unseres oembed Endpunkts umgewandelt.
Nun ist unser Anliegen in erster Linie, dass Miniaturen angezeigt werden, wenn Topic List Thumbnails aktiv ist. Ich bin mir nicht sicher, warum die Miniaturansicht nicht erkannt wird.
Zusätzlich funktioniert das Standardverhalten heute größtenteils, abgesehen davon, dass unsere dynamischen Einbettungen nicht unterstützt werden. Wir möchten JS anstelle eines Iframes laden. Zugegebenermaßen gibt es dafür eine andere Lösung, nämlich das optionale Ändern der Größe des Iframes mit etwas JS, aber wir planen nicht, dies kurzfristig generisch für oEmbeds zu implementieren.
Nach einiger Diskussion mit dem Discourse-Team per E-Mail aktualisiere ich hier.\n\nDie wichtigste Erkenntnis ist, dass Thumbnails nicht geladen werden, wenn ein Link, der zu einem Onebox wird, als iFrame gerendert wird.\n\nDas bedeutet, dass der Link:\n\nx\nhttps://app.everviz.com/embed/N0dDTJaOQ\n\n\nabhängig davon, ob iFrames von der Domain zugelassen sind (allowed iframes), ein Thumbnail rendert oder nicht. Die Lösung dafür ist, irgendwie einen iFrame in den Beitrag einzufügen. Ich habe ein Plugin erstellt, das dies tut und sicherstellt, dass display: none auf dem Bild gesetzt wird, um zu verhindern, dass es im Beitrag erscheint.\n\nIch stelle mir vor, dass dies verallgemeinert werden könnte, entweder durch:\n\n1. Für alle generischen Oneboxen wird lautlos ein Bild daneben geladen und ausgeblendet, wenn get_oembed.thumbnail_url existiert.\n2. Wahrscheinlich eine bessere Lösung, allgemeine Unterstützung für die Extraktion von get_oembed.thumbnail_url und die Zuordnung zu dem Beitrag, ohne dass er selbst Teil des cooked-Bereichs ist.\n\nRelevante Stellen:\n1. https://oembed.com/\n2. https://github.com/discourse/discourse/tree/main/lib/onebox/engine\n3. https://github.com/discourse/discourse/blob/main/lib/onebox/engine/standard_embed.rb\n\nIch bin mit diesem modalen Verhalten nicht sehr zufrieden, d.h. ist allowed iframes aktiviert oder nicht? Es wäre schön, wenn Discourse alle Eigenschaften eines gegebenen oembed-Endpunkts extrahieren und nutzen würde, wenn es zum ersten Mal einen GET-Request daran sendet.
Wir sind zu spät und Discourse hat die Miniaturansicht bereits abgerufen und generiert.
Uns fehlen einige Attribute in unserem Bild, die dazu führen, dass der Mechanismus zur Generierung von Miniaturansichten es übersieht.
Hoffentlich ist es letzteres. Eine Sache, die hier zu beachten ist, ist, dass das Bild niemals auf unsere Discourse-Instanz hochgeladen wird, sondern einfach von unserem eigenen Server referenziert wird.
Haben Sie das ausprobiert? Das Schreiben einer spezifischen Onebox für Ihren Fall könnte es Ihnen ermöglichen, ein Onebox-Bild für den verarbeiteten Beitrag bereitzustellen? Dann würden Miniaturansichten automatisch funktionieren.
Ich stelle fest, dass Youtube-Oneboxen meiner Meinung nach statische In-Site-Inhalte sind, bis Sie auf die Wiedergabetaste klicken und dann ein iFrame angezeigt wird. Der Inhalt, der vor dem Klick angezeigt wird, enthält ein Bild, das dann aufgenommen und als Miniaturansicht angezeigt wird. Offensichtlich kann Discourse nicht aus einem iFrame lesen, daher ist diese Technik ein guter Ansatz.
Ich stelle fest, dass Ihr Beispiel ein og:image in den Header-Tags enthält, was perfekt ist.
Mein Vorschlag ist, hier von JavaScript wegzukommen und in Rails zu kochen.
Der einzige Nachteil dabei ist, dass Ihr Bild statisch ist, bis Sie den Beitrag neu erstellen, vorausgesetzt, das Zielbild wird ebenfalls aktualisiert. Wenn Sie also ein dynamisch wechselndes Miniaturbild anzeigen möchten, müssen Sie möglicherweise noch kreativer werden.
Das Schreiben eines Plugins war das Erste, was ich tat, und das funktionierte fantastisch – egal, ob ich es in lib/onebox/engine oder als separates Plugin einfügte. Der Nachteil ist, dass wir uns in einem gehosteten Plan befinden, bei dem Plugins auf Multi-Tenant-Plänen verständlicherweise nicht erlaubt sind, sodass das Kochen in Rails außer Frage steht.
Das lässt uns mit einer von drei Möglichkeiten:
Eine eigene Instanz betreiben
Etwas auf der Client-Seite hacken, falls es funktionieren könnte
Um hier eine Frage zu stellen. Ich bin mir nicht sicher, ob ein solcher Beitrag angenommen würde, insbesondere wenn er ein Bild lädt, nur um es zu verstecken. Wie könnte ich das herausfinden?
Ich habe hier vielleicht einige Fortschritte gemacht. Wenn man sich Folgendes ansieht:\n\napi.composerBeforeSave\n\nDessen Callback wird in composer.js behandelt. Von dort aus können wir sehen, dass die Methoden createPost und editPostgetCookedHtml aufrufen, was mehr oder weniger einfach das innerHTML von Folgendem zurückgibt:\n\njs\nconst editorPreviewNode = document.querySelector(\n \"#reply-control .d-editor-preview\"\n);\n\n\nDas bedeutet, wenn wir diesen Selektor ändern würden, könnten wir möglicherweise HTML erzwingen, das einer normalen Bild-Upload-Funktion entspricht. Es scheint jedoch, dass das Ändern von editorPreviewNode.innerHTML keine Änderung bewirkt.\n\nWarum ist das so, oder was kann ich in composerBeforeSave ändern, um etwas Ähnliches zu tun?
Das ergibt für mich größtenteils Sinn. Ich denke, wir wären offen dafür, einen PR an den Core für eine Onebox-Engine für everviz.com (oder ähnliche Visualisierungsdienste) anzunehmen. Ich würde jedoch vermeiden, ein Bild in den cooked-Beitrag einzufügen und zu verstecken. Es gibt eine leichtere Option. Der Post-Prozessor von Discourse sucht nach einem Upload der folgenden Elemente:
Könnte das Hinzufügen des Thumbnails als Anker unterhalb des Iframes funktionieren? Sie könnten es sichtbar lassen oder es mit einer Klasse wie “hidden” verstecken.
Dies scheint so zu sein, als ob die image_onebox.rb-Engine nur auf die Eingabe angewendet wird, wenn ein Bild außerhalb des Kontexts einer anderen Onebox-Engine verknüpft ist.
Die Konsequenz daraus ist, dass die vorgeschlagene Technik derzeit nicht funktioniert und es notwendig ist, ein Bild zu verknüpfen und zu verstecken oder Discourse zu modifizieren, um dies zu berücksichtigen.
Wäre es in diesem Fall akzeptabel, ein Bild einzufügen und zu verstecken? Oder ist etwas Aufwändigeres notwendig?
Entschuldigen Sie die Verwirrung, die Ausgabe sah dem Onebox-Engine für Bilder ähnlich.
Der vorgeschlagene Link (ordnungsgemäß mit einer UUID versehen) funktioniert nicht. Auch dieses Bild, das ich von Google bezogen habe (und hier als Anker-Tag schreibe. Wenn das Einfügen von HTML der Ausgabe eines Onebox gleichkommt, würde dies unsere Ergebnisse erklären.
Ah, mein Fehler, Sie haben Recht, dieser Ansatz funktioniert nicht. Wenn wir Thumbnails generieren, verwenden wir nur heruntergeladene Bilder, aber Bilder, die in einem Anker-Tag verlinkt sind, werden nicht heruntergeladen.
Eine Alternative hier könnte sein, dem Kern etwas Ähnliches hinzuzufügen, wie @merefield empfohlen hat, aber als generischer Oneboxer für Lazy-Loading-Iframes verpackt. Vielleicht eine neue Site-Einstellung lazy_loaded_iframes hinzufügen, und die Onebox kann zunächst das Bild aus dem OG-Tag ausgeben (das von den Thumbnails erfasst werden sollte) und beim Klicken ersetzt ein wenig JS das Bild durch den korrekten Iframe (ähnlich wie beim Ersetzen des Youtube-Iframes).
Ein kniffliges Detail hierbei ist, dass das verwendete Bild und der Iframe die gleiche Höhe haben sollten, da dies sonst unerwünschte Sprünge beim Scrollen/Navigieren durch Beiträge verursachen kann.
