Tenemos el plugin de Wordpress configurado para publicar temas completos en una categoría de anuncios en nuestro foro. Esto funciona bastante bien, pero los mensajes de correo electrónico que Discourse envía están marcados como Content-Type: text/plain; charset=UTF-8.
Según entiendo, esto es técnicamente cierto, ya que el formato esperado es markdown, que es algo así como texto plano. Pero, por supuesto, markdown también, para bien o para mal, incluye “html también es válido, ¡yolo!”.
Y, de hecho, las publicaciones de Wordpress son un montón de HTML.
¿Cómo están lidiando otros con esto? ¿Hay alguna forma de que las publicaciones en Discourse sean un markdown razonable para humanos después de todo? ¿O hay alguna forma de forzar el tipo de contenido HTML para el correo generado en esta categoría? ¿O… alguna otra idea? ¡Gracias!
¿Por “mensajes” te refieres a las notificaciones por correo electrónico que recibes de Discourse sobre nuevas publicaciones en tu categoría de anuncios?
Solo estoy tratando de entender el punto de dolor específico del usuario que estás tratando de abordar aquí.
Sí, lo siento. Con “mensajes” me refería a “mensajes de correo electrónico”. Y con “ello” me refería a Discourse, no al plugin de Wordpress. Editaré la publicación principal para que quede claro.
En mi imaginación, lo más agradable sería que los mensajes de correo electrónico fueran multipartes con un text/plain renderizado en markdown y un text/html separado. Pero ni siquiera estoy seguro de cómo funcionaría eso.
Disculpe, para aclarar de nuevo, ¿está planteando esto porque las notificaciones por correo electrónico de las publicaciones de Discourse que contienen HTML (por ejemplo, publicaciones vinculadas a publicaciones de Wordpress en su categoría de anuncios) contienen incorrectamente entidades HTML? Si es así, ¿podría compartir un ejemplo?
La razón por la que insisto en esto es que la generación de notificaciones por correo electrónico en Discourse está bastante separada de cualquier cosa relacionada con el plugin de Wordpress. Las notificaciones por correo electrónico tienen su propia canalización y hay múltiples formas en las que puede terminar con entidades HTML en una publicación de Discourse, siendo una publicación de Wordpress solo una.
En otras palabras, el hecho de que haya HTML en una publicación de Discourse es un problema diferente al de lo que contienen las notificaciones por correo electrónico sobre esa publicación y cómo están codificadas. Comprender el problema específico que está experimentando / planteando ayudará a que las personas adecuadas presten atención a él.
Puede que esté entendiendo mal lo que está pasando, pero esto es lo que creo que está sucediendo:
Se publica la entrada de WordPress.
El plugin responde a eso y crea una entrada en Discourse.
Las entradas de Discourse son todas Markdown, pero resulta que la entrada que viene de WordPress a través del plugin es un desastre de HTML (lo cual es perfectamente válido en Markdown).
Los usuarios suscritos a notificaciones por correo electrónico reciben un correo electrónico que contiene ese texto, que parece un desastre de HTML.
Me doy cuenta de que alguien podría crear manualmente una entrada en Discourse con un montón de HTML de la misma manera, pero en la práctica eso no suele ser un problema (y si lo fuera, se podría resolver en su mayor parte con un educado “oye, ¿podrías no hacerlo?”).
Se ve así, tanto en Discourse si vas a editar la publicación como cuando se envía:
<small>Publicado originalmente en: https://communityblog.fedoraproject.org/cpe-hiring-a-software-engineer/
</small><br><p>El grupo de Ingeniería de Plataformas Comunitarias, o CPE por sus siglas en inglés, es el equipo de Red Hat que combina ingeniería de TI y de lanzamiento para Fedora y CentOS. Actualmente tenemos una vacante abierta para un <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">ingeniero de software en India</a>.</p>
<h2>Acerca del puesto</h2>
<p>Estamos <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">contratando nuevo talento</a> para que trabaje a tiempo completo en Fedora, principalmente como parte de nuestro grupo de Ingeniería de Lanzamiento. Podrás trabajar en la infraestructura que construye y distribuye los artefactos y actualizaciones de lanzamiento de Fedora Linux. Este puesto es perfecto para cualquier persona con experiencia o interés en Ingeniería de Lanzamiento.</p>
<h2>Acerca de CPE</h2>
<p>Nuestro objetivo es mantener en funcionamiento y mantener los servidores y servicios principales, construir lanzamientos y realizar otras tareas estratégicas que requieren más tiempo dedicado del que los voluntarios pueden ofrecer.</p>
<p>Consulta <a href="https://docs.fedoraproject.org/en-US/cpe/">nuestra documentación</a> para obtener más información. ¡Esperamos conocerte y, con suerte, trabajar contigo pronto!</p>
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/plain renderizado en markdown limpio y un text/html separado.
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.