D’accord, 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 il s’agit de problèmes distincts.
Entités HTML dans les notifications par e-mail en texte brut
la meilleure solution serait que les messages e-mail soient multipartites, avec une version texte brut rendue en markdown
text/plainet une version séparéetext/html.
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 Discourse, vous verrez qu’il existe une version texte et une version HTML.
Ce que vous semblez dire, bien que je ne sois pas encore tout à fait certain de bien comprendre, c’est que vous recevez des entités HTML dans la version texte brut des notifications par e-mail Discourse, ce qui a pour conséquence que vous voyez les entités HTML réelles dans le corps de l’e-mail lorsque vous le consultez avec un client de messagerie qui ne prend pas en charge le HTML. Est-ce bien cela que vous voulez dire ? Pourriez-vous partager une capture d’écran de cela depuis un client de messagerie (qui ne prend pas en charge le HTML) ?
Si c’est bien 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é sur Support ou Contribute > Bug.
HTML dans les messages Discourse
Vous soulevez ici un problème pertinent, mais d’un point de vue technique, la question réside dans la façon dont Discourse aborde le contenu importé de manière plus globale. La valeur par défaut actuelle pour le contenu importé est le HTML, et non le markdown.
D’autres contextes dans lesquels vous pouvez observer cela incluent le plugin RSS Polling, qui, comme le plugin WP Discourse, importe du HTML dans le contenu des messages. Notez également que le paramètre site embed support markdown est désactivé par défaut, ainsi que tous les autres paramètres site concernant l’intégration de HTML dans les messages (par exemple, allowed embed selectors).
Je fais ici une hypothèse, mais la raison la plus probable de cette décision stratégique prise dès les premiers jours de la gestion du contenu importé par Discourse est une combinaison de simplicité et de fidélité, c’est-à-dire que les conversions de HTML vers markdown seront imparfaites. Il y a une exception clé à cela, que j’aborderai ci-dessous.
Le plugin WP Discourse pourrait tenter de convertir le HTML des messages 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 variantes de markdown.
En effet, le fait que le plugin WP Discourse tente de gérer la conversion serait en réalité malavisé, car Discourse dispose déjà d’un convertisseur personnalisé HtmlToMarkdown. Actuellement, ce convertisseur gère la conversion du HTML en markdown pour les e-mails importés dans Discourse. Si le HTML des messages provenant 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 messages, 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 optionnel). Vous pourriez plaider en faveur de cette fonctionnalité et, si elle est implémentée, le plugin WP Discourse l’adopterait comme un paramètre optionnel.