Discourse ahora admite puntos finales nativos de Markdown, lo que facilita a las herramientas de IA y a otros clientes leer el contenido del foro sin tener que analizar páginas HTML completas.
Esta función se habilitará de forma predeterminada en todos los sitios alojados a través del sistema de Próximos Cambios. Los administradores que deseen excluirse pueden hacerlo deshabilitando la configuración del sitio enable_markdown_endpoints.
Muchas gracias a @benword por crear el plugin original Discourse to Markdown, que fue el precursor de esta función en el núcleo de Discourse.
La salida en Markdown se genera a partir del HTML renderizado (“cocinado”) de las publicaciones, preservando el contenido que ven los lectores, incluyendo enlaces expandidos y formato procesado. Los elementos específicos de Discourse, como citas, oneboxes, bloques de código, encuestas y secciones plegables, se convierten de nuevo a Markdown. Las respuestas de los temas incluyen metadatos y enlaces de paginación, y los cuerpos de publicaciones convertidos se almacenan en caché utilizando un resumen de contenido para que las ediciones produzcan una salida actualizada.
Los clientes pueden solicitar Markdown explícitamente mediante URLs .md o enviando una cabecera Accept: text/markdown. La negociación respeta los valores de calidad y selecciona Markdown cuando se prefiere sobre HTML y JSON; las solicitudes explícitas de .md conservan sus formatos. Las páginas HTML compatibles anuncian su equivalente en Markdown a través de una cabecera HTTP Link y un elemento <link rel="alternate">.
Dado que actualmente estoy utilizando el plugin original de Discourse a Markdown, ¿necesito desactivarlo y eliminarlo para evitar conflictos en las salidas? Por favor, indíqueme.
Una duda: para quienes usan el proxy de Cloudflare, parece haber un conflicto entre la función del núcleo y su herramienta de conversión. La pregunta es: si estoy detrás del proxy, ¿dado que la función es para suscriptores, impedirán que la cabecera se convierta de HTML a .md, o, al tener soporte en el cliente para la conversión, esta se realiza independientemente de ello?
Sí. Si el plugin permanece habilitado, reemplaza algunos de los puntos de acceso (endpoints) principales, por lo que recomendamos desactivarlo/desinstalarlo para utilizar la funcionalidad que ahora forma parte del núcleo.
Actualmente, las siguientes:
Soportadas
Ejemplos
Listas principales
/latest.md, /hot.md, /top.md
Listas personalizadas, que requieren autenticación
/new.md, /unread.md
Listas de categoría/subcategoría predeterminadas
/c/support/6.md, /c/parent/child/12.md
Listas de una sola etiqueta
/tag/example.md, /tag/example/123.md
/categories.md y /tags.md también están soportadas como directorios. Definiciones de rutas
No estoy muy familiarizado con la función de Cloudflare, pero por lo que puedo ver, captura la solicitud Accept text/markdown antes de que llegue al servidor, convierte el HTML y luego sirve ese resultado. Por lo tanto, parece que esa función anularía la de Discourse si se utiliza Cloudflare.
Lo sobrescribiría si estuviera habilitado, ¿verdad? No encontré en su blog ninguna información sobre si impiden que el propio origen sirva esa cabecera.
No lo sé con certeza, la opción más sencilla es probarlo en un sitio en vivo y comparar la salida con lo que genera Meta. Habrá diferencias en el contenido incluido. Si la respuesta que obtienes es la misma con o sin la función de Cloudflare, entonces está respetando el Markdown devuelto por el núcleo de Discourse.
X-Discourse-Crawler-View: true (indicando que Discourse también proporciona una versión limpia en .md / Markdown nativo para rastreadores y lectores).
El encabezado Link que indica la versión alternativa: Link: <https://segredin.com/t/conselhos-duvidosos/22054.md>; rel="alternate"; type="text/markdown"
Devuelve Vary: Accept desde el origen, independientemente de las funciones externas a nivel de DNS.
Si la solicitud opta por realizar una petición sin el .json, devolverá el .md como conversión predeterminada.
HTTP/1.1 200 OK
Content-Type: text/markdown
Vary: Accept
Me quedé con la duda porque recibí 123 mil solicitudes de Claude y la mayoría, desde que actualicé Discourse con esta función del núcleo, no aumentó de forma vertiginosa. Lo vigilaré durante las próximas semanas.
Gracias, me confundí porque primero lo probé en una lista de temas filtrada por categoría y etiqueta, y no funcionó. Suelo elegir malos ejemplos para las pruebas.
¿Por qué incluiste /new y /unread pero no /unseen?
¿Tiene la intención el núcleo de que los bloques discourse-post-event tengan una representación dedicada en Markdown, de la misma manera que ya ocurre con las encuestas, las citas, los oneboxes y las secciones plegables? Técnicamente, añadir una parece bastante viable: detectar div.discourse-post-event, leer sus atributos data-* y reemplazarlo por un bloque Markdown preservado antes de la pasada genérica de ReverseMarkdown.