Ja, wenn Sie sich voll in diese Richtung bewegen würden, müssten Sie darauf verzichten, Inhalte in Discourse bearbeiten zu können, um die vollständige HTML-Integrität zu wahren.
Ich dachte, es könnte einen Mittelweg geben, bei dem Sie diesen Ansatz nur auf img-Tags in importierten HTML-Beiträgen anwenden.
Aber ich zweifle jetzt daran. Eine selektive Umsetzung würde Änderungen in vielen Teilen der Beitragsverarbeitung erfordern.
Ja, ich denke, das ist wahrscheinlich die beste Option. Ich habe im Juni 2020 bereits damit begonnen, aber es erwies sich als sehr aufwendig, und ich musste mich anderen Projekten zuwenden. Ich hatte zwei Ansätze, um upload://-URLs in <img>-Tags zu ermöglichen – keiner davon ist perfekt. Aus meinen Notizen:
Im Markdown-Pipeline die Inhalte jedes html_block analysieren (durch eine leichte Umgehung der xss.js-Bibliothek) und alle Bild-Tag mit upload://-src-Attributen verarbeiten.
Vorteile: Alles in der Markdown-Pipeline, erfolgt nur bei html_block-Tokens.
Nachteile: Die xss.js-Sanitizer wird gewissermaßen missbraucht. Sie ist möglicherweise kein perfekter HTML5-Parser.
Diese Option ließe sich verbessern, indem eine standardskonforme JavaScript-DOM-Implementierung (z. B. jsdom) auf dem Server verwendet wird, doch das scheint recht aufwendig zu sein.
Erlaube upload://-src-Attribute durchgehend in der Markdown-Pipeline und ersetze sie später. Auf der Client-Seite ist dies tatsächlich recht einfach – wir ersetzen upload://-URLs bereits asynchron nach dem „Cooking“. Auf der Server-Seite wird dabei ein zusätzlicher Verarbeitungsschritt mit Nokogiri durchgeführt.
Vorteile: Der Parser ist HTML5-konform.
Nachteile: Unterschiedliche Implementierung auf Client- und Server-Seite, macht die Pipeline etwas komplexer.
Ich denke, Option 2 ist wahrscheinlich der richtige Weg. Anschließend müssen wir den pull_hotlinked_images-Job aktualisieren, um <img>-Tags beizubehalten, ohne sie durch Markdown zu ersetzen. Ich hoffe, ich finde bald wieder Zeit, mich diesem Thema wieder zu widmen 
Ich verstehe die Komplikation hier wirklich nicht. Offensichtlich wird das HTML-Bild-Tag durch Markdown ersetzt – z. B. . Warum nicht einfach zwei Wagenrückläufe vor das ! setzen? Das würde dafür sorgen, dass es korrekt gerendert wird, und die Bild-Upload-Funktion würde funktionieren, um defekte Bilder und Cross-Site-Probleme zu vermeiden.
Gibt es eine reale, nicht-theoretische Situation, in der dieses Leerzeichen ein Problem verursachen könnte? Ist dieses Problem schlimmer als der aktuelle Zustand des Plugins, bei dem Bilder ständig kaputt sind?
@david, du stellst fest, dass die „Lösung mit dem Zeilenumbruch wahrscheinlich nicht umgesetzt wird“, weil „das Wichtigste für uns darin besteht, die Integrität des Inhalts zu wahren“. Aber der Inhalt wird bereits verändert, indem die Tags eingefügt werden. Ich… verstehe wirklich nicht, wie das irgendwie besser sein soll.
Im Moment sind jedes Mal, wenn jemand ein Bild in seinen WordPress-Beitrag einfügt, die Bilder defekt, und ich muss häufig mit Kommentaren wie „Bilder sind kaputt“ umgehen, die nun oft von Antworten wie „Ja, das liegt daran, dass Discourse scheiße ist“ gefolgt werden. Ich möchte beides vermeiden.
Ich verstehe, dass die Einstellung „Bilder nicht herunterladen“ eine Workaround-Lösung sein könnte, aber eigentlich möchte ich, dass Bilder heruntergeladen werden. Hoffentlich kann das also nur eine vorübergehende Lösung sein.
Dies sollte behoben sein durch:
Lass es uns hier auf Meta ausprobieren.
<div>
Bild in einem HTML-Block:
<img src="..." width=100 height=100>
</div>
Dieses Thema wurde nach 5 Tagen automatisch geschlossen. Neue Antworten sind nicht mehr möglich.
