Discourse prend désormais en charge les points d’accès Markdown natifs, facilitant la lecture du contenu des forums par les outils IA et autres clients, sans avoir à analyser des pages HTML complètes.
Cette fonctionnalité sera activée par défaut sur tous les sites hébergés via le système « Upcoming Changes ». Les administrateurs souhaitant s’en exclure peuvent le faire en désactivant le changement à venir enable_markdown_endpoints sur /admin/config/upcoming-changes?changeNamesFilter=enable_markdown_endpoints :
Merci beaucoup à @benword pour avoir créé le plugin original Discourse to Markdown, qui a été le précurseur de cette fonctionnalité dans le noyau de Discourse.
La sortie Markdown est générée à partir du HTML rendu (« cuit ») des messages, préservant ainsi le contenu visible par les lecteurs, y compris les liens dépliés et le formatage traité. Les éléments spécifiques à Discourse tels que les citations, oneboxes, blocs de code, sondages et sections repliables sont convertis en Markdown. Les réponses aux sujets incluent des métadonnées et des liens de pagination, et les corps de message convertis sont mis en cache à l’aide d’un digest de contenu afin que les modifications produisent une sortie actualisée.
Les clients peuvent demander explicitement le format Markdown via des URL .md ou en envoyant l’en-tête Accept: text/markdown. La négociation respecte les valeurs de qualité et sélectionne le Markdown lorsqu’il est préféré au HTML et au JSON ; les requêtes explicites .md conservent leurs formats. Les pages HTML prises en charge annoncent leur équivalent Markdown via un en-tête HTTP Link et un élément <link rel="alternate">.
Comme j’utilise actuellement le plugin original Discourse-to-Markdown, dois-je le désactiver et le supprimer pour éviter des conflits dans les sorties ? Merci de me conseiller.
Une question : pour ceux qui utilisent le proxy de Cloudflare, il semble y avoir un conflit entre la fonction du noyau et leur outil de conversion. La question est la suivante : si je suis derrière le proxy, étant donné que la fonction est réservée aux abonnés, vont-ils empêcher la conversion de l’en-tête du HTML vers le .md, ou, compte tenu du support de la conversion côté client, cela se produit-il indépendamment de cela ?
Oui. Si le plugin reste activé, il remplace certains des points d’accès (endpoints) principaux. Nous recommandons donc de le désactiver ou de le désinstaller afin d’utiliser la fonctionnalité désormais intégrée au cœur du système.
Actuellement, les suivantes :
Pris en charge
Exemples
Listes principales
/latest.md, /hot.md, /top.md
Listes personnalisées, nécessitant une authentification
/new.md, /unread.md
Listes de catégories/sous-catégories par défaut
/c/support/6.md, /c/parent/child/12.md
Listes de balises uniques
/tag/example.md, /tag/example/123.md
/categories.md et /tags.md sont également pris en charge en tant que répertoires. Définitions des routes
Je ne suis pas très familier avec la fonctionnalité Cloudflare, mais d’après ce que je comprends, elle intercepte la requête Accept text/markdown avant qu’elle n’atteigne le serveur, convertit le HTML et sert ensuite le résultat. Il semble donc que cette fonctionnalité prendrait le pas sur celle de Discourse, si/elle est utilisée avec Cloudflare.
Il l’écraserait s’il était activé, n’est-ce pas ? Je n’ai trouvé aucune information sur leur blog indiquant s’ils empêchent l’origine elle-même de fournir cet en-tête.
Je ne suis pas sûr à 100 %, mais la solution la plus simple est de tester sur un site en production et de comparer la sortie avec ce que génère Meta. Il y aura des différences dans le contenu inclus. Si la réponse obtenue est identique avec ou sans la fonctionnalité de Cloudflare, alors elle respecte le Markdown renvoyé par le cœur de Discourse.
X-Discourse-Crawler-View: true (indiquant que Discourse met également à disposition une version propre en .md / Markdown natif pour les robots d’indexation et les lecteurs).
L’en-tête Link indiquant la version alternative : Link: <https://segredin.com/t/conselhos-duvidosos/22054.md>; rel="alternate"; type="text/markdown"
Retourne Vary: Accept depuis l’origine, indépendamment des fonctions externes au niveau DNS.
Si la demande choisit d’effectuer une requête sans .json, elle renverra le .md comme conversion par défaut.
HTTP/1.1 200 OK
Content-Type: text/markdown
Vary: Accept
J’ai eu un doute parce que j’ai reçu 123 000 requêtes de Claude et que la plupart, depuis que j’ai mis à jour Discourse avec cette fonction du noyau, n’ont pas augmenté de manière vertigineuse. Je vais continuer à surveiller la situation au cours des prochaines semaines.
Merci, j’étais confus car j’avais d’abord essayé sur une liste de sujets filtrée par catégorie et par étiquette, et ça n’a pas fonctionné. J’ai tendance à choisir de mauvais exemples pour mes tests.
Pourquoi avez-vous inclus /new et /unread mais pas /unseen ?
Le cœur de Discourse prévoit-il que les blocs discourse-post-event disposent d’une représentation Markdown dédiée, de la même manière que les sondages, les citations, les oneboxes et les sections repliables en ont déjà ? Techniquement, l’ajout d’un tel support dans CookedProcessor semble tout à fait réalisable : détecter div.discourse-post-event, lire ses attributs data-*, puis le remplacer par un bloc Markdown préservé avant le passage générique de ReverseMarkdown.
Je l’ai désactivé, mais il m’indique que je ne pourrai pas choisir de sitôt. Je ne veux pas rendre les choses trop faciles aux robots d’indexation, et cette vue contourne certaines méthodes que j’utilise pour repérer les bots.
Petite remarque au cas où ce serait utile : un mois après son activation ici, markdown-endpoint:cooked:* comptait environ un million de clés, soit 87 % de notre espace de clés Redis (~570 Mo). Presque tout provenait de bots récupérant les pages .md, chaque publication étant mise en cache pendant une semaine. Cela semble représenter beaucoup de Redis pour une seule fonctionnalité.
Ce qui me rend curieux concernant l’autre aspect. Avez-vous déjà vu de vrais visiteurs y revenir ? Cela rendrait la décision de le réactiver facile.
