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/plainund einer separatentext/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.