O Discourse agora suporta endpoints nativos em Markdown, facilitando a leitura do conteúdo do fórum por ferramentas de IA e outros clientes, sem a necessidade de analisar páginas HTML completas.
Este recurso será ativado por padrão em todos os sites hospedados por meio do sistema de Próximas Alterações. Administradores que desejarem desativá-lo podem fazê-lo desabilitando a configuração do site enable_markdown_endpoints.
Muito obrigado ao @benword por criar o plugin original Discourse to Markdown, que foi o precursor deste recurso no núcleo do Discourse.
A saída em Markdown é gerada a partir do HTML renderizado (“cozido”) das publicações, preservando o conteúdo visto pelos leitores, incluindo links expandidos e formatação processada. Elementos específicos do Discourse, como citações, oneboxes, blocos de código, enquetes e seções recolhíveis, são convertidos de volta para Markdown. As respostas de tópicos incluem metadados e links de paginação, e os corpos das publicações convertidos são armazenados em cache usando um resumo de conteúdo, garantindo que edições gerem uma saída atualizada.
Os clientes podem solicitar explicitamente o formato Markdown por meio de URLs com .md ou enviando o cabeçalho Accept: text/markdown. A negociação respeita os valores de qualidade e seleciona o Markdown quando ele é preferível ao HTML e ao JSON; solicitações explícitas com .md mantêm seus formatos. As páginas HTML suportadas anunciam seu equivalente em Markdown por meio de um cabeçalho HTTP Link e de um elemento <link rel="alternate">.
Como estou atualmente usando o plugin original Discourse-to-Markdown, preciso desativá-lo e removê-lo para evitar conflitos na saída? Por favor, orientem-me.
Uma dúvida: para quem usa o proxy da Cloudflare, parece haver um conflito entre a função do núcleo e a ferramenta deles de conversão. A pergunta é: se eu estiver por trás do proxy, pelo fato da função ser para assinantes, eles vão impedir que o cabeçalho seja convertido de HTML para .md, ou, por ter suporte no cliente à conversão, ela acontece independente disso?
Sim. Se o plugin permanecer ativado, ele substitui alguns dos endpoints principais, portanto, recomendamos desativá-lo/desinstalá-lo para usar a funcionalidade que agora está no núcleo.
Atualmente, as seguintes:
Suportado
Exemplos
Listas principais
/latest.md, /hot.md, /top.md
Listas personalizadas, exigindo autenticação
/new.md, /unread.md
Listas padrão de categoria/subcategoria
/c/support/6.md, /c/parent/child/12.md
Listas de tag única
/tag/example.md, /tag/example/123.md
/categories.md e /tags.md são suportados adicionalmente como diretórios. Definições de rota
Não estou muito familiarizado com o recurso do Cloudflare, mas pelo que posso ver, ele intercepta a solicitação Accept text/markdown antes que ela atinja o servidor, converte o html e então serve isso. Portanto, parece que esse recurso do Cloudflare sobrescreveria o do Discourse, se/quando estiver usando o Cloudflare.
Sobrescreveria se estiver habilitado, certo? Não achei no blog deles nenhuma informação sobre se eles impedem que a própria origem sirva esse cabeçalho.
Não tenho certeza, mas a opção mais fácil é testar em um site ao vivo e comparar a saída com o que o meta produz. Haverá diferenças no conteúdo incluído. Se a resposta que você receber for a mesma com ou sem o recurso do Cloudflare, então ele está respeitando o Markdown retornado pelo núcleo do Discourse.
X-Discourse-Crawler-View: true (mostrando que o Discourse também disponibiliza uma versão limpa em .md / Markdown nativo para crawlers e leitores).
O header Link indicando a versão alternativa: Link: <https://segredin.com/t/conselhos-duvidosos/22054.md>; rel="alternate"; type="text/markdown"
Retorna o Vary: Accept pela origem independente de funções externas a nível de DNS.
Se o pedido optar por fazer uma request sem o .json, ele vai retornar o .md como conversão padrão.
HTTP/1.1 200 OK
Content-Type: text/markdown
Vary: Accept
Eu fiquei em dúvida porque recebi 123 mil requisições da Claude e a maioria, desde que atualizei o Discourse com essa função do núcleo, não subiu de forma vertiginosa. Vou acompanhar pelas próximas semanas.
Obrigado, eu estava confuso porque primeiro tentei em uma lista de tópicos filtrada por uma categoria e uma tag, e não funcionou. Eu tenho a tendência de escolher exemplos ruins para testar.
Por que você incluiu /new e /unread, mas não /unseen?
O núcleo (core) tem a intenção de que os blocos discourse-post-event tenham uma representação dedicada em Markdown, da mesma forma que enquetes, citações, oneboxes e seções recolhíveis já possuem? Tecnicamente, adicionar um ao CookedProcessor parece bastante viável: detectar div.discourse-post-event, ler seus atributos data-* e substituí-lo por um bloco Markdown preservado antes da passagem genérica do ReverseMarkdown.