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>
…これはあまり役に立ちません。
はい、ここで指摘されている問題については個別に対応させていただきます。なぜそれらを関連づけて捉えているのかは理解できますが、これらが別々の問題である理由もご理解いただけるはずです。
最も望ましいのは、メールメッセージをマルチパートにし、整形されたマークダウンの
text/plainと独立したtext/htmlを含めることです
実はこれが現在、Discourseのメール通知で採用されている動作です。Discourseのメール通知の「元のメッセージ」を確認すると、テキスト版とHTML版の両方が含まれていることがわかります。
おそらく言いたいのは、Discourseのメール通知のプレーンテキスト版にHTMLエンティティが含まれており、その結果、HTMLをサポートしていないメールクライアントでメール本文を表示した際に、実際のHTMLエンティティがそのまま表示されてしまう、ということではないでしょうか？ もしそうであれば、HTMLをサポートしていないメールクライアントでのスクリーンショットを共有していただけますか？
もしこれが事実であれば、これはDiscourseのメールコンテンツ生成およびフォーマットに固有の問題であり、Support または Contribute > Bug のより焦点を絞ったトピックに分離するのが最善です。
ここで指摘されている点は関連性がありますが、技術的な観点からは、この問題はDiscourseがインポートされたコンテンツをより広範な観点からどのように扱っているかにあります。現在、インポートされたコンテンツのデフォルトはマークダウンではなくHTMLです。
この現象が見られる他のコンテキストとしては、RSS Polling plugin があります。このプラグインもWP Discourseプラグインと同様に、HTMLを投稿コンテンツとしてインポートします。また、embed support markdown サイト設定はデフォルトでオフになっており、投稿内の埋め込みHTMLに関連する他のサイト設定（例: allowed embed selectors）も同様です。
私は推測を含んでいますが、Discourseがインポートされたコンテンツを扱う初期段階でこの戦略的判断が下された主な理由は、シンプルさと忠実度の両立、つまりHTMLからマークダウンへの変換が完全にはいかないという点の組み合わせだったと思われます。ただし、後述する重要な例外が一つあります。
WP Discourseプラグインは、WordPressの投稿のHTMLをDiscourseに送信する前にマークダウンに変換しようと試みることができます。確かに、HTMLをマークダウンに変換する既存のPHPライブラリは存在しますが、特にマークダウンにはさまざまな方言があることを考慮すると、マークアップ言語の変換はそれほど単純な問題ではありません。
実際、WP Discourseプラグインが変換処理を行うのは誤りであると考えられます。なぜなら、Discourseには既にカスタムの HtmlToMarkdown コンバーターが存在するからです。現在、このコンバーターはDiscourseにインポートされるメール内のHTMLからマークダウンへの変換を処理しています。WordPressからの投稿のHTMLをDiscourseのマークダウンに変換する場合、その変換はこのコンバーターによって処理される必要があります。
現在、WP DiscourseプラグインはDiscourse API、具体的には /posts エンドポイントを使用して投稿を公開しています。つまり、あなたが言いたいのは、Discourseの /posts エンドポイントに HtmlToMarkdown コンバーターのサポートを追加してほしい（オプションのクエリパラメータとして）、ということではないでしょうか？ この提案を支持することができ、実装されればWP Discourseプラグインはこれをオプション設定として採用するでしょう。