Wordpress プラグインは、フォーラムの告知カテゴリに完全なトピックを投稿するように設定されています。これはかなりうまく機能しますが、Discourse が送信するメール メッセージは Content-Type: text/plain; charset=UTF-8 とマークされます。
私の理解では、これは技術的には正しいです。期待される形式は Markdown であり、それはある意味プレーンテキストです。しかし、Markdown は、良くも悪くも、「HTML も有効です、イェーイ！」も含まれています。
実際、Wordpress からの投稿は HTML の塊です。
他の人はどのように対処していますか？投稿された Discourse バージョンを、人間が読める妥当な Markdown にする方法はありますか？または、このカテゴリで生成されるメールのコンテンツ タイプを強制的に HTML にする方法はありますか？あるいは… 他に何かアイデアはありますか？よろしくお願いします！
確認のため、@mattdm さんにお伺いします。あなたが次のように言ったとき、
「メッセージ」とは、Discourse から新しい投稿に関するメール通知のことですか？
ここで解決しようとしている具体的なユーザーのペインポイントを理解しようとしています。
はい、すみません。「メッセージ」とは「電子メールメッセージ」のことでした。そして「それ」とはWordPressプラグインではなく、Discourseのことでした。トップ投稿を編集して、それを明確にします。
私の想像では、最も良いのは、電子メールメッセージがプレーンテキストでレンダリングされたマークダウンの text/plain と、別の text/html を持つマルチパートであることです。しかし、それがどのように機能するのかさえわかりません。
申し訳ありません、再度明確にするために、Discourseの投稿（たとえば、お知らせカテゴリのWordPress投稿にリンクされた投稿）のHTMLを含む電子メール通知にHTMLエンティティが誤って含まれているために、これを提起していますか？もしそうであれば、例を共有していただけますか？
この件を追求している理由は、Discourseの電子メール通知の生成は、WordPressプラグインに関連するあらゆるものとは全く別だからです。電子メール通知には独自のパイプラインがあり、Discourseの投稿にHTMLエンティティが含まれるようになるには複数の方法があり、WordPressからの投稿はそのうちの1つにすぎません。
つまり、Discourseの投稿にHTMLが含まれているという事実は、その投稿に関する電子メール通知に含まれるものやエンコード方法とは別の問題です。あなたが抱えている、または提起している特定の問題を理解することで、適切な担当者の注意を引くことができます。
私の理解が間違っているかもしれませんが、以下が起こっていることだと思います。
誰かが手動で同じように大量のHTMLを含むDiscourseの投稿を作成することも可能であることは理解していますが、実際にはそれは通常問題になりません（もし問題になったとしても、「ねえ、やめてくれない？」と丁寧に言えばほとんど解決できます）。
これで意味が通じることを願っています。
例：この投稿
Discourseで投稿を編集するときや、送信されるときに、次のように表示されます。
<small>Originally published at: https://communityblog.fedoraproject.org/cpe-hiring-a-software-engineer/
</small><br><p>The Community Platform Engineering group, or CPE for short, is the Red Hat team combining IT and release engineering for Fedora and CentOS. We currently have a position open for a <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">software engineer in India</a>.</p>
<h2>About the role</h2>
<p>We are <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">hiring new talent</a> to come work full time on Fedora, primarily as part of our Release Engineering group. You’ll get to work on the infrastructure that builds and ships the Fedora Linux release artifacts and updates. This role is perfect for anyone with experience or interest in Release Engineering.</p>
<h2>About CPE</h2>
<p>Our goal is to keep core servers and services running and maintained, build releases, and perform other strategic tasks that need more dedicated time than volunteers can give.</p>
<p>See <a href="https://docs.fedoraproject.org/en-US/cpe/">our docs</a> for more information. We are looking forward to meeting you and hopefully working with you soon!</p>
…これはあまり役に立ちません。
承知いたしました。提起されている問題には、それぞれ個別に回答します。それらを結びつけている理由は理解できますが、なぜ別個の問題なのか、ご理解いただけると幸いです。
最善の方法は、メールメッセージをマルチパートにし、クリーンなテキストでレンダリングされたMarkdownの
text/plainと、個別のtext/htmlにすることです。
これは、実際にはDiscourseのメール通知が現在機能している方法です。Discourseのメール通知の「オリジナル」を見ると、テキストバージョンとHTMLバージョンの両方があることがわかります。
あなたが言おうとしていることは、Discourseのメール通知のプレーンテキストバージョンにHTMLエンティティが含まれているということだと思いますが、まだ100％明確ではありません。その結果、HTMLをサポートしていないメールクライアントで表示した場合、メール本文に実際のHTMLエンティティが表示されるということです。そうでしょうか？HTMLをサポートしていないメールクライアントからのスクリーンショットを共有していただけますか？
もしそうであれば、これはDiscourseのメールコンテンツ生成とフォーマットに固有の問題であり、より的を絞ったトピックとして #support または #bug に切り分けるのが最善でしょう。
これは関連性の高い問題を提起していますが、技術的な観点からは、Discourseがインポートされたコンテンツをより広範に扱う方法に関する問題です。現在、インポートされたコンテンツのデフォルトはMarkdownではなくHTMLです。
これが見られる他のコンテキストとしては、RSS Polling plugin があります。これは、WP Discourse pluginと同様に、HTMLを投稿コンテンツにインポートします。また、embed support markdown サイト設定はデフォルトでオフになっており、投稿内の埋め込みHTMLを処理する他のすべてのサイト設定（例：allowed embed selectors）も同様です。
これは推測に過ぎませんが、Discourseがインポートされたコンテンツを処理する初期段階でこの戦略的な決定が下された最も可能性の高い理由（複数）は、シンプルさと忠実性の組み合わせ、つまりHTMLからMarkdownへの変換は不完全になるということです。これには1つの重要な例外があり、以下で言及します。
WP Discourse pluginは、WordPressの投稿のHTMLをMarkdownに変換してからDiscourseに送信しようとすることができます。はい、HTMLをMarkdownに変換する既存のPHPライブラリはありますが、マークアップ言語を変換する場合、特にMarkdownのさまざまなフレーバーを考慮すると、それほど単純ではありません。
実際、WP Discourse pluginが変換を処理しようとすることは、DiscourseにすでにカスタムのHtmlToMarkdownコンバーターが存在することを考えると、誤解を招くでしょう。現在、このコンバーターは、DiscourseにインポートされたメールのHTMLからMarkdownへの変換を処理しています。WordPressからの投稿のHTMLをDiscourse Markdownに変換する場合、そのコンバーターによって処理される必要があります。
現在、WP Discourse pluginはDiscourse APIを使用して投稿を発行しています。つまり、/posts エンドポイントです。したがって、あなたが言っているのは、Discourseの/posts エンドポイントに（つまり、オプションのクエリパラメータとして）HtmlToMarkdown コンバーターサポートを追加してほしいということです。これについて提唱すれば、実装された場合、WP Discourse pluginはそれをオプション設定として採用するでしょう。