Wir haben das Wordpress-Plugin so eingerichtet, dass vollständige Themen in eine Ankündigungskategorie in unserem Forum gepostet werden. Das funktioniert ziemlich gut, aber die E-Mail-Nachrichten, die Discourse sendet, sind mit Content-Type: text/plain; charset=UTF-8 gekennzeichnet.
Soweit ich weiß, ist das technisch korrekt, da das erwartete Format Markdown ist, was irgendwie Plain-Text ist. Aber Markdown beinhaltet natürlich auch, ob gut oder schlecht, “HTML ist auch gültig, yolo!”.
Und tatsächlich sind die Beiträge von Wordpress eine Menge HTML.
Wie gehen andere damit um? Gibt es eine Möglichkeit, die in Discourse geposteten Versionen als vernünftiges, menschenlesbares Markdown zu erhalten? Oder gibt es eine Möglichkeit, den für diese Kategorie generierten E-Mails den Content-Type HTML aufzuzwingen? Oder… irgendwelche anderen Ideen? Danke!
Ja, Entschuldigung. Mit „Nachrichten“ meinte ich „E-Mail-Nachrichten“. Und mit „es“ meinte ich Discourse, nicht das Wordpress-Plugin. Ich werde den oberen Beitrag bearbeiten, um das klarzustellen.
In meiner Vorstellung wäre das Schönste, wenn die E-Mail-Nachrichten mehrteilig wären, mit einem sauberen Text, der Markdown rendert (text/plain), und einem separaten text/html. Aber ich bin mir nicht einmal sicher, wie das funktionieren würde.
Entschuldigung, nur um das noch einmal zu klären: Erhöhen Sie dies, weil E-Mail-Benachrichtigungen über Discourse-Beiträge, die HTML enthalten (z. B. Beiträge, die in Ihrer Ankündigungskategorie mit WordPress-Beiträgen verknüpft sind), falsch HTML-Entitäten enthalten? Wenn ja, können Sie ein Beispiel teilen?
Der Grund, warum ich darauf dränge, ist, dass die Generierung von E-Mail-Benachrichtigungen in Discourse ziemlich getrennt von allem ist, was mit dem WordPress-Plugin zu tun hat. E-Mail-Benachrichtigungen haben ihre eigene Pipeline und es gibt mehrere Möglichkeiten, wie HTML-Entitäten in einem Discourse-Beitrag landen können, wobei ein Beitrag von WordPress nur einer davon ist.
Mit anderen Worten: Die Tatsache, dass HTML in einem Discourse-Beitrag vorhanden ist, ist ein anderes Problem als das, was E-Mail-Benachrichtigungen über diesen Beitrag enthalten und wie sie kodiert sind. Das Verständnis des spezifischen Problems, das Sie haben / ansprechen, wird dazu beitragen, die richtigen Augen und die richtige Aufmerksamkeit darauf zu lenken.
Ich verstehe vielleicht nicht ganz, was vor sich geht, aber hier ist, was ich denke, was passiert:
Der WordPress-Beitrag wird veröffentlicht.
Das Plugin reagiert darauf und erstellt einen Discourse-Beitrag.
Discourse-Beiträge sind alle Markdown, aber es passiert, dass der Beitrag von WordPress über das Plugin ein Durcheinander von HTML ist (was in Markdown völlig gültig ist).
Benutzer, die per E-Mail für Benachrichtigungen angemeldet sind, erhalten eine E-Mail mit diesem Text – der wie ein Durcheinander von HTML aussieht.
Ich erkenne, dass jemand manuell einen Discourse-Beitrag mit einer Menge HTML auf die gleiche Weise erstellen könnte, aber praktisch ist das normalerweise kein Problem (und wenn es eines wäre, könnte es meistens mit einem höflichen „Hey, könntest du das nicht tun?“ gelöst werden).
sieht so aus, sowohl in Discourse, wenn Sie den Beitrag bearbeiten, als auch wenn er gesendet wird:
<small>Ursprünglich veröffentlicht unter: https://communityblog.fedoraproject.org/cpe-hiring-a-software-engineer/
</small><br><p>Die Community Platform Engineering-Gruppe, kurz CPE, ist das Red Hat-Team, das Release Engineering für Fedora und CentOS kombiniert. Wir haben derzeit eine Stelle für einen <a href="https://global-redhat.icims.com/jobs/96157/software-engineer/job?mobile=true&width=412&height=732&bga=true&needsRedirect=false&jan1offset=-480&jun1offset=-420">Softwareentwickler in Indien</a> zu besetzen.</p>
<h2>Über die Rolle</h2>
<p>Wir <a href="https://global-redhat.icims.com/jobs/96157/software-engineer/job?mobile=true&width=412&height=732&bga=true&needsRedirect=false&jan1offset=-480&jun1offset=-420">stellen neue Talente ein</a>, die Vollzeit an Fedora arbeiten, hauptsächlich als Teil unserer Release Engineering-Gruppe. Sie werden an der Infrastruktur arbeiten, die die Fedora Linux-Release-Artefakte und -Updates erstellt und ausliefert. Diese Rolle ist perfekt für alle mit Erfahrung oder Interesse an Release Engineering.</p>
<h2>Über CPE</h2>
<p>Unser Ziel ist es, Kernserver und -dienste am Laufen zu halten und zu warten, Releases zu erstellen und andere strategische Aufgaben durchzuführen, die mehr Zeit erfordern, als Freiwillige aufwenden können.</p>
<p>Weitere Informationen finden Sie in <a href="https://docs.fedoraproject.org/en-US/cpe/">unserer Dokumentation</a>. Wir freuen uns darauf, Sie kennenzulernen und hoffentlich bald mit Ihnen zusammenzuarbeiten!</p>
Okay, ich werde auf die von dir angesprochenen Punkte separat eingehen. Ich verstehe, warum du sie verknüpfst, aber hoffentlich erkennst du später, warum es sich um getrennte Probleme handelt.
HTML-Entitäten in E-Mail-Benachrichtigungen als Klartext
Das Schönste wäre, wenn die E-Mail-Nachrichten mehrteilig wären, mit einem sauberen, als Markdown gerenderten text/plain und einer separaten text/html-Version.
So funktionieren Discourse-E-Mail-Benachrichtigungen tatsächlich derzeit. Wenn du dir den “Originalinhalt” einer Discourse-E-Mail-Benachrichtigung ansiehst, wirst du sehen, dass es sowohl eine Textversion als auch eine HTML-Version gibt.
Was du scheinbar sagst – wobei ich hier noch nicht zu 100 % sicher bin – ist, dass du HTML-Entitäten in der Klartextversion der Discourse-E-Mail-Benachrichtigungen erhältst. Das Ergebnis ist, dass du die tatsächlichen HTML-Entitäten im E-Mail-Text siehst, wenn du die E-Mail in einem E-Mail-Client öffnest, der kein HTML unterstützt. Ist das das, was du meinst? Könntest du einen Screenshot davon aus einem E-Mail-Client (der kein HTML unterstützt) teilen?
Falls dem so ist, handelt es sich um ein spezifisches Problem bei der Generierung und Formatierung von Discourse-E-Mail-Inhalten. Es wäre am besten, dies in ein gezielteres Thema in Support oder Contribute > Bug auszulagern.
HTML in Discourse-Beiträgen
Du bringst hier ein relevantes Problem zur Sprache, aber aus technischer Sicht liegt die Frage darin, wie Discourse importierte Inhalte im Allgemeinen handhabt. Der aktuelle Standard für importierte Inhalte ist HTML, nicht Markdown.
Andere Kontexte, in denen du dies sehen kannst, ist das RSS-Polling-Plugin, das – wie das WP Discourse-Plugin – HTML in den Beitragsinhalt importiert. Beachte auch, dass die Site-Einstellung embed support markdown standardmäßig deaktiviert ist und alle anderen Site-Einstellungen, die sich mit eingebettetem HTML in Beiträgen befassen (z. B. allowed embed selectors).
Ich vermute hier teilweise, aber der wahrscheinlichste Grund für diese strategische Entscheidung in den frühen Tagen von Discourse bei der Handhabung importierter Inhalte war eine Kombination aus Einfachheit und Treue zur Originalstruktur, d. h. Konvertierungen von HTML zu Markdown werden unvollkommen sein. Es gibt eine wichtige Ausnahme davon, auf die ich weiter unten eingehen werde.
Das WP Discourse-Plugin könnte versuchen, das HTML von WordPress-Beiträgen in Markdown zu konvertieren, bevor sie an Discourse gesendet werden. Ja, es gibt bereits PHP-Bibliotheken, die HTML in Markdown konvertieren, aber es ist nie so einfach, wie es scheint, wenn es um die Konvertierung einer Auszeichnungssprache geht, insbesondere wenn man die verschiedenen Markdown-Varianten berücksichtigt.
Tatsächlich wäre es sogar kontraproduktiv, wenn das WP Discourse-Plugin die Konvertierung übernehmen würde, da es in Discourse bereits einen benutzerdefinierten HtmlToMarkdown-Konverter gibt. Derzeit behandelt dieser Konverter die Konvertierung von HTML zu Markdown bei in Discourse importierten E-Mails. Wenn das HTML von Beiträgen aus WordPress in Discourse-Markdown konvertiert werden sollte, müsste dies von diesem Konverter übernommen werden.
Derzeit verwendet das WP Discourse-Plugin die Discourse-API, um Beiträge zu veröffentlichen, d. h. den /posts-Endpunkt. Im Wesentlichen sagst du also, dass du möchtest, dass der HtmlToMarkdown-Konverter-Support zum Discourse-/posts-Endpunkt hinzugefügt wird (d. h. als optionaler Query-Parameter). Du könntest dich für diese Änderung einsetzen, und falls sie implementiert wird, würde das WP Discourse-Plugin sie als optionale Einstellung übernehmen.