Discourse prend désormais en charge les points d’accès Markdown natifs, facilitant ainsi la lecture du contenu des forums par les outils d’IA et d’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 des modifications à venir. Les administrateurs qui souhaitent s’en exclure peuvent le faire en désactivant le paramètre de site enable_markdown_endpoints.
Merci beaucoup à @benword pour avoir créé le plugin Discourse to Markdown d’origine, qui a servi de précurseur à cette fonctionnalité dans le noyau de Discourse.
La sortie Markdown est générée à partir du HTML rendu (« cuit ») des messages, préservant le contenu vu par les lecteurs, y compris les liens développés et la mise en forme traitée. Les éléments spécifiques à Discourse, tels que les citations, les oneboxes, les blocs de code, les sondages et les 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 messages convertis sont mis en cache à l’aide d’un digest de contenu afin que les modifications produisent une sortie fraîche.
Les clients peuvent demander explicitement le Markdown via des URL .md ou en envoyant un 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 .md explicites conservent leurs formats. Les pages HTML prises en charge indiquent 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.