Ok, je vais répondre séparément aux problèmes que vous soulevez ici. Je comprends pourquoi vous les reliez, mais j’espère que vous verrez pourquoi ce sont des problèmes distincts.
Entités HTML dans les notifications par e-mail en texte brut
La meilleure chose à faire serait que les messages électroniques soient multipartites avec un rendu en texte brut
text/plainet untext/htmlséparé.
C’est en fait ainsi que fonctionnent actuellement les notifications par e-mail de Discourse. Si vous regardez l’“original” d’une notification par e-mail de Discourse, vous verrez qu’il existe une version texte et une version HTML.
Ce que vous semblez dire, mais je ne suis toujours pas sûr à 100%, c’est que vous recevez des entités HTML dans la version texte brut des notifications par e-mail de Discourse, le résultat étant que vous voyez les entités HTML réelles dans le corps de l’e-mail lorsque vous le consultez dans un client de messagerie qui ne prend pas en charge le HTML. Est-ce bien cela que vous dites ? Pourriez-vous partager une capture d’écran de cela à partir d’un client de messagerie (qui ne prend pas en charge le HTML) ?
Si tel est le cas, il s’agit d’un problème spécifique à la génération et au formatage du contenu des e-mails de Discourse, et il serait préférable de le séparer dans un sujet plus ciblé dans Support ou Bug.
HTML dans les publications Discourse
Vous soulevez un problème pertinent ici, mais d’un point de vue technique, la question réside dans la manière dont Discourse aborde le contenu importé de manière plus générale. Le réglage par défaut actuel pour le contenu importé est le HTML, pas le markdown.
D’autres contextes dans lesquels vous pouvez le voir sont le plugin RSS Polling, qui, comme le plugin WP Discourse, importe du HTML dans le contenu des publications. Notez également que le paramètre du site embed support markdown est désactivé par défaut et tous les autres paramètres du site traitant du HTML intégré dans les publications (par exemple, allowed embed selectors).
Je suppose en partie, mais la raison la plus probable de cette décision stratégique prise aux premiers temps de la gestion du contenu importé par Discourse est une combinaison de simplicité et de fidélité, c’est-à-dire que les conversions du HTML au markdown seront imparfaites. Il y a une exception clé à cela que je mentionnerai ci-dessous.
Le plugin WP Discourse pourrait tenter de convertir le HTML des publications Wordpress en markdown avant de les envoyer à Discourse. Oui, il existe des bibliothèques PHP existantes qui convertissent le HTML en markdown, mais ce n’est jamais aussi simple que cela lorsqu’il s’agit de convertir un langage de balisage, en particulier compte tenu des différentes saveurs de markdown.
En fait, le fait que le plugin WP Discourse tente de gérer la conversion serait une erreur, étant donné qu’il existe déjà un convertisseur personnalisé HtmlToMarkdown dans Discourse. Actuellement, ce convertisseur gère la conversion du HTML en markdown dans les e-mails importés dans Discourse. Si le HTML des publications de Wordpress devait être converti en markdown Discourse, cela devrait être géré par ce convertisseur.
Actuellement, le plugin WP Discourse utilise l’API Discourse pour publier des articles, c’est-à-dire le point de terminaison /posts. Donc, essentiellement, ce que vous dites, c’est que vous souhaitez que le support du convertisseur HtmlToMarkdown soit ajouté au point de terminaison /posts de Discourse (c’est-à-dire en tant que paramètre de requête facultatif). Vous pourriez plaider en faveur de cela et, si cela est implémenté, le plugin WP Discourse l’adoptera comme un réglage facultatif.