Nous avons configuré le plugin Wordpress pour publier des sujets complets dans une catégorie d’annonces sur notre forum. Cela fonctionne assez bien, mais les messages électroniques envoyés par Discourse sont marqués Content-Type: text/plain; charset=UTF-8.
D’après ce que je comprends, c’est techniquement vrai, car le format attendu est le markdown, qui est en quelque sorte du texte brut. Mais, bien sûr, le markdown inclut aussi, pour le meilleur ou pour le pire, « HTML est aussi valide, yolo ! ».
Et, en fait, les publications provenant de Wordpress sont un tas de HTML.
Comment les autres gèrent-ils cela ? Existe-t-il un moyen d’obtenir que les versions publiées sur Discourse soient un markdown raisonnablement lisible par l’homme après tout ? Ou existe-t-il un moyen de forcer le type de contenu HTML pour les e-mails générés dans cette catégorie ? Ou… d’autres idées ? Merci !
Par « messages », entendez-vous les notifications par e-mail que vous recevez de Discourse concernant les nouveaux messages dans votre catégorie d’annonces ?
J’essaie juste de comprendre le point de douleur spécifique que vous essayez d’aborder ici.
Oui, désolé. Par « messages », j’entendais « e-mails ». Et par « il », j’entendais Discourse, pas le plugin Wordpress. Je vais modifier le message principal pour clarifier cela.
Dans mon imagination, la meilleure chose serait que les messages électroniques soient multi-parties avec un rendu markdown en texte brut text/plain et un text/html séparé. Mais je ne suis même pas sûr de la façon dont cela fonctionnerait.
Désolé, juste pour clarifier à nouveau, soulevez-vous ce point parce que les notifications par e-mail des publications Discourse contenant du HTML (par exemple, les publications liées à des publications Wordpress dans votre catégorie d’annonces) contiennent incorrectement des entités HTML ? Si oui, pourriez-vous partager un exemple ?
La raison pour laquelle j’insiste sur ce point est que la génération des notifications par e-mail dans Discourse est assez distincte de tout ce qui est lié au plugin Wordpress. Les notifications par e-mail ont leur propre pipeline et il existe plusieurs façons d’obtenir des entités HTML dans une publication Discourse, une publication provenant de Wordpress n’étant qu’une seule.
En d’autres termes, le fait qu’il y ait du HTML dans une publication Discourse est un problème différent de ce que contiennent les notifications par e-mail concernant cette publication et de la manière dont elles sont encodées. Comprendre le problème spécifique que vous rencontrez / soulevez aidera à attirer les bonnes personnes et la bonne attention sur celui-ci.
Je crois que je ne comprends pas bien ce qui se passe, mais voici ce que je pense qu’il se passe :
Le message WordPress est publié.
Le plugin y répond et crée un message Discourse.
Les messages Discourse sont tous en Markdown, mais il se trouve que le message venant de WordPress via le plugin est un fouillis de HTML (ce qui est parfaitement valide en Markdown).
Les utilisateurs abonnés aux notifications par e-mail reçoivent un e-mail contenant ce texte — qui ressemble à un fouillis de HTML.
Je me rends compte que quelqu’un pourrait manuellement créer un message Discourse avec un tas de HTML de la même manière, mais en pratique ce n’est généralement pas un problème (et si cela en était un, on pourrait le résoudre la plupart du temps par un simple « hé, tu pourrais éviter ? »).
Ressemble à ceci, à la fois dans Discourse si vous modifiez le post et lorsqu’il est envoyé :
<small>Publié à l'origine sur : https://communityblog.fedoraproject.org/cpe-hiring-a-software-engineer/
</small><br><p>Le groupe Community Platform Engineering, ou CPE pour faire court, est l'équipe Red Hat qui combine l'ingénierie informatique et l'ingénierie de publication pour Fedora et CentOS. Nous avons actuellement un poste ouvert pour 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">ingénieur logiciel en Inde</a>.</p>
<h2>À propos du rôle</h2>
<p>Nous <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">recrutons de nouveaux talents</a> pour travailler à temps plein sur Fedora, principalement dans le cadre de notre groupe Release Engineering. Vous travaillerez sur l'infrastructure qui construit et expédie les artefacts et les mises à jour de la version Fedora Linux. Ce rôle est parfait pour toute personne ayant de l'expérience ou un intérêt pour la Release Engineering.</p>
<h2>À propos du CPE</h2>
<p>Notre objectif est de maintenir les serveurs et services principaux en fonctionnement et entretenus, de construire les versions et d'effectuer d'autres tâches stratégiques qui nécessitent plus de temps dédié que ce que les bénévoles peuvent donner.</p>
<p>Voir <a href="https://docs.fedoraproject.org/en-US/cpe/">nos docs</a> pour plus d'informations. Nous avons hâte de vous rencontrer et, espérons-le, de travailler avec vous bientôt !</p>
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/plain et un text/html sé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.