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>
Ok, ich werde separat auf die von Ihnen angesprochenen Probleme eingehen. Ich verstehe, warum Sie sie miteinander verbinden, aber hoffentlich werden Sie sehen, warum es sich um getrennte Probleme handelt.
HTML-Entitäten in einfachen Text-E-Mail-Benachrichtigungen
Das Schönste wäre, wenn die E-Mail-Nachrichten mehrteilig wären, mit einem sauberen Text-gerenderten Markdown text/plain und einem separaten text/html.
Dies ist tatsächlich die Funktionsweise der E-Mail-Benachrichtigungen von Discourse. Wenn Sie sich das “Original” einer Discourse-E-Mail-Benachrichtigung ansehen, werden Sie feststellen, dass es eine Textversion und eine HTML-Version gibt.
Was Sie zu sagen scheinen, aber ich bin mir immer noch nicht zu 100 % sicher, ist, dass Sie HTML-Entitäten in der einfachen Textversion von Discourse-E-Mail-Benachrichtigungen erhalten, mit dem Ergebnis, dass Sie die tatsächlichen HTML-Entitäten im Text der E-Mail sehen, wenn Sie sie in einem E-Mail-Client betrachten, der kein HTML unterstützt. Ist das, was Sie sagen? Könnten Sie einen Screenshot davon aus einem E-Mail-Client (der kein HTML unterstützt) teilen?
Wenn dies der Fall ist, handelt es sich um ein Problem, das spezifisch für die E-Mail-Inhaltsgenerierung und -formatierung von Discourse ist, und es wäre am besten, dies in einem gezielteren Thema unter Support oder Bug abzutrennen.
HTML in Discourse-Posts
Sie sprechen hier ein relevantes Problem an, aber aus technischer Sicht liegt die Frage bei der Art und Weise, wie Discourse importierte Inhalte im Allgemeinen behandelt. Die aktuelle Standardeinstellung für importierte Inhalte ist HTML, nicht Markdown.
Andere Kontexte, in denen Sie dies sehen können, sind das RSS Polling Plugin, das, wie das WP Discourse Plugin, HTML in den Post-Inhalt importiert. Beachten Sie auch, dass die Website-Einstellung embed support markdown standardmäßig deaktiviert ist und alle anderen Website-Einstellungen, die sich mit eingebettetem HTML in Beiträgen befassen (z. B. allowed embed selectors).
Ich rate hier teilweise, aber der wahrscheinlichste Grund für diese strategische Entscheidung in den frühen Tagen der Discourse-Verarbeitung importierter Inhalte war eine Kombination aus Einfachheit und Treue, d. h. Konvertierungen von HTML zu Markdown werden unvollkommen sein. Es gibt eine wichtige Ausnahme, die ich unten erwähnen werde.
Das WP Discourse Plugin könnte versuchen, das HTML von WordPress-Posts in Markdown zu konvertieren, bevor es sie an Discourse sendet. Ja, es gibt bestehende PHP-Bibliotheken, die HTML in Markdown konvertieren, aber das ist nie so einfach, wenn man eine Markup-Sprache konvertiert, insbesondere angesichts der verschiedenen Markdown-Varianten.
Tatsächlich wäre es irreführend, wenn das WP Discourse Plugin versuchen würde, die Konvertierung zu handhaben, da es bereits einen benutzerdefinierten HtmlToMarkdown-Konverter in Discourse gibt. Derzeit handhabt dieser Konverter die Konvertierung von HTML in Markdown in E-Mails, die in Discourse importiert werden. 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. Was Sie also im Wesentlichen sagen, ist, dass Sie möchten, dass die HtmlToMarkdown-Konverterunterstützung zum Discourse /posts-Endpunkt hinzugefügt wird (d. h. als optionaler Query-Parameter). Sie könnten dafür werben, und wenn dies implementiert wird, würde das WP Discourse Plugin es als optionale Einstellung übernehmen.