Temos o plugin do Wordpress configurado para postar tópicos completos em uma categoria de anúncios em nosso fórum. Isso funciona muito bem, mas as mensagens de e-mail que o Discourse envia são marcadas como Content-Type: text/plain; charset=UTF-8.
Pelo que entendi, isso é Tecnicamente Verdadeiro, pois o formato esperado é markdown, que é uma espécie de texto simples. Mas, é claro, markdown também, para o bem ou para o mal, inclui “html também é válido, yolo!”.
E, de fato, as postagens vindas do Wordpress são um monte de HTML.
Como outras pessoas estão lidando com isso? Existe alguma maneira de fazer com que as postagens enviadas para o Discourse sejam um markdown razoável como texto humano, afinal? Ou existe alguma maneira de forçar o tipo de conteúdo HTML para o e-mail gerado nesta categoria? Ou… alguma outra ideia? Obrigado!
Sim, desculpe. Por “mensagens” eu quis dizer “mensagens de e-mail”. E por “isso” eu quis dizer Discourse, não o plugin do Wordpress. Vou editar a postagem principal para deixar isso claro.
Na minha imaginação, a coisa mais legal seria as mensagens de e-mail serem multipartes com um text/plain renderizado em markdown limpo e um text/html separado. Mas eu nem tenho certeza de como isso funcionaria.
Desculpe, apenas para esclarecer novamente, você está levantando isso porque as notificações por e-mail de postagens do Discourse contendo HTML (por exemplo, postagens vinculadas a postagens do Wordpress em sua categoria de anúncios) contêm incorretamente entidades HTML? Se sim, você poderia compartilhar um exemplo?
O motivo pelo qual estou insistindo nisso é que a geração de notificações por e-mail no Discourse é bastante separada de qualquer coisa relacionada ao plugin do Wordpress. As notificações por e-mail têm seu próprio pipeline e existem várias maneiras de você acabar com entidades HTML em uma postagem do Discourse, sendo uma postagem do Wordpress apenas uma delas.
Em outras palavras, o fato de haver HTML em uma postagem do Discourse é um problema diferente do que as notificações por e-mail sobre essa postagem contêm e como elas são codificadas. Entender o problema específico que você está tendo / levantando ajudará a direcionar os olhos e a atenção corretos para ele.
Talvez eu esteja entendendo mal o que está acontecendo, mas aqui está o que acho que está acontecendo:
A postagem do WordPress é publicada.
O plugin responde a isso e cria uma postagem no Discourse.
As postagens do Discourse são todas em Markdown, mas acontece que a postagem vinda do WordPress através do plugin é uma bagunça de HTML (o que é perfeitamente válido em Markdown).
Usuários inscritos em notificações por e-mail recebem um e-mail contendo esse texto — que parece uma bagunça de HTML.
Percebo que alguém poderia criar manualmente uma postagem no Discourse com um monte de HTML da mesma forma, mas na prática isso geralmente não é um problema (e se fosse, poderia ser resolvido na maioria das vezes com um educado “ei, você poderia não fazer isso?”).
Parece com isto, tanto no Discourse se você editar a postagem quanto quando enviada:
<small>Publicado originalmente em: https://communityblog.fedoraproject.org/cpe-hiring-a-software-engineer/
</small><br><p>O grupo Community Platform Engineering, ou CPE para abreviar, é a equipe da Red Hat que combina engenharia de TI e de lançamento para Fedora e CentOS. Atualmente, temos uma vaga aberta para um <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">engenheiro de software na Índia</a>.</p>
<h2>Sobre a função</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 novos talentos</a> para trabalhar em tempo integral no Fedora, principalmente como parte de nosso grupo de Engenharia de Lançamento. Você trabalhará na infraestrutura que constrói e envia os artefatos e atualizações de lançamento do Fedora Linux. Esta função é perfeita para qualquer pessoa com experiência ou interesse em Engenharia de Lançamento.</p>
<h2>Sobre o CPE</h2>
<p>Nosso objetivo é manter os servidores e serviços principais em funcionamento e mantidos, construir lançamentos e realizar outras tarefas estratégicas que exigem mais tempo dedicado do que os voluntários podem oferecer.</p>
<p>Veja <a href="https://docs.fedoraproject.org/en-US/cpe/">nossos docs</a> para mais informações. Estamos ansiosos para conhecê-lo e, esperançosamente, trabalhar com você em breve!</p>
Ok, vou responder às questões que você levanta aqui separadamente. Entendo por que você as está conectando, mas espero que veja por que são questões separadas.
Entidades HTML em notificações de e-mail de texto simples
O ideal seria que as mensagens de e-mail fossem multipartes com um text/plain renderizado em markdown limpo e um text/html separado.
Na verdade, é assim que as notificações de e-mail do Discourse funcionam atualmente. Se você olhar o “original” de uma notificação de e-mail do Discourse, verá que há uma versão em texto e uma versão em HTML.
O que você parece estar dizendo, mas ainda não tenho 100% de clareza sobre isso, é que você está recebendo entidades HTML na versão de texto simples das notificações de e-mail do Discourse, com o resultado de que você está vendo as entidades HTML reais no corpo do e-mail ao visualizá-lo em um cliente de e-mail que não suporta HTML. É isso que você está dizendo? Você poderia compartilhar uma captura de tela disso de um cliente de e-mail (que não suporta HTML)?
Se for esse o caso, este é um problema específico da geração e formatação de conteúdo de e-mail do Discourse e seria melhor separá-lo em um tópico mais direcionado em Support ou Bug.
HTML em posts do Discourse
Você levanta uma questão relevante aqui, mas, de uma perspectiva técnica, a questão reside em como o Discourse aborda o conteúdo importado de forma mais ampla. A configuração padrão atual para conteúdo importado é HTML, não markdown.
Outros contextos em que você pode ver isso é o plugin RSS Polling, que, assim como o plugin WP Discourse, importa HTML para o conteúdo do post. Observe também que a configuração do site embed support markdown está desativada por padrão e todas as outras configurações do site que lidam com HTML incorporado em posts (por exemplo, allowed embed selectors).
Estou adivinhando em parte, mas o(s) motivo(s) mais provável(is) para essa decisão estratégica ter sido tomada nos primórdios do Discourse ao lidar com conteúdo importado foi uma combinação de simplicidade e fidelidade, ou seja, as conversões de HTML para markdown serão imperfeitas. Há uma exceção importante a isso, que mencionarei abaixo.
O plugin WP Discourse poderia tentar converter o HTML dos posts do WordPress para markdown antes de enviá-los para o Discourse. Sim, existem bibliotecas PHP existentes que convertem HTML para markdown, mas nunca é tão simples assim ao converter uma linguagem de marcação, especialmente considerando os diferentes sabores de markdown.
De fato, o plugin WP Discourse tentar lidar com a conversão seria equivocado, considerando que já existe um conversor personalizado HtmlToMarkdown no Discourse. Atualmente, este conversor lida com a conversão de HTML para markdown em e-mails importados para o Discourse. Se o HTML de posts do WordPress fosse convertido para markdown do Discourse, ele precisaria ser tratado por esse conversor.
Atualmente, o plugin WP Discourse usa a API do Discourse para publicar posts, ou seja, o endpoint /posts. Então, essencialmente, o que você está dizendo é que deseja que o suporte do conversor HtmlToMarkdown seja adicionado ao endpoint /posts do Discourse (ou seja, como um parâmetro de consulta opcional). Você poderia defender isso e, se implementado, o plugin WP Discourse o adotaria como uma configuração opcional.