De acuerdo, responderé a los problemas que planteas aquí por separado. Entiendo por qué los conectas, pero espero que veas por qué son problemas separados.
Entidades HTML en notificaciones por correo electrónico de texto plano
Lo más conveniente sería que los mensajes de correo electrónico fueran multipartes con un
text/plainrenderizado en markdown limpio y untext/htmlseparado.
De hecho, así es como funcionan actualmente las notificaciones por correo electrónico de Discourse. Si miras el “original” de una notificación por correo electrónico de Discourse, verás que hay una versión de texto y una versión HTML.
Lo que parece que estás diciendo, pero aún no estoy 100% seguro de esto, es que estás recibiendo entidades HTML en la versión de texto plano de las notificaciones por correo electrónico de Discourse, con el resultado de que ves las entidades HTML reales en el cuerpo del correo electrónico cuando lo miras en un cliente de correo electrónico que no admite HTML. ¿Es eso lo que estás diciendo? ¿Podrías compartir una captura de pantalla de esto desde un cliente de correo electrónico (que no admita HTML)?
Si este es el caso, es un problema específico de la generación y formato de contenido de correo electrónico de Discourse y sería mejor separarlo en un tema más específico en Support o Bug.
HTML en publicaciones de Discourse
Planteas un problema relevante aquí, pero desde una perspectiva técnica, la cuestión radica en cómo Discourse aborda el contenido importado en general. La configuración predeterminada actual para el contenido importado es HTML, no markdown.
Otros contextos en los que puedes ver esto es el plugin RSS Polling, que, al igual que el plugin WP Discourse, importa HTML al contenido de la publicación. Ten en cuenta también que la configuración del sitio embed support markdown está desactivada por defecto y todas las demás configuraciones del sitio relacionadas con la incrustación de HTML en las publicaciones (por ejemplo, allowed embed selectors).
Estoy adivinando en parte, pero la razón o razones más probables por las que se tomó esta decisión estratégica en los primeros días de Discourse para manejar el contenido importado fue una combinación de simplicidad y fidelidad, es decir, las conversiones de HTML a markdown serán imperfectas. Hay una excepción clave a esto que mencionaré a continuación.
El plugin WP Discourse podría intentar convertir el HTML de las publicaciones de WordPress a markdown antes de enviarlas a Discourse. Sí, existen bibliotecas PHP existentes que convierten HTML a markdown, pero nunca es tan simple como eso al convertir un lenguaje de marcado, especialmente considerando los diferentes sabores de markdown.
De hecho, el plugin WP Discourse que intenta manejar la conversión sería un error, considerando que ya existe un conversor personalizado HtmlToMarkdown en Discourse. Actualmente, este conversor maneja la conversión de HTML a markdown en correos electrónicos importados a Discourse. Si el HTML de las publicaciones de WordPress se convirtiera a markdown de Discourse, tendría que ser manejado por ese conversor.
Actualmente, el plugin WP Discourse utiliza la API de Discourse para publicar, es decir, el endpoint /posts. Así que, esencialmente, lo que estás diciendo es que quieres que se agregue soporte para el conversor HtmlToMarkdown al endpoint /posts de Discourse (es decir, como un parámetro de consulta opcional). Podrías abogar por esto y, si se implementa, el plugin WP Discourse lo adoptaría como una configuración opcional.