Discourse supporta ora gli endpoint Markdown nativi, rendendo più semplice per gli strumenti di AI e altri client leggere i contenuti del forum senza dover analizzare intere pagine HTML.
Questa funzionalità sarà abilitata per impostazione predefinita su tutti i siti ospitati tramite il sistema Upcoming Changes. Gli amministratori che desiderano non attivarla possono farlo disabilitando l’impostazione di sito enable_markdown_endpoints.
Molti ringraziamenti a @benword per aver creato il plugin originale Discourse to Markdown, che è stato il precursore di questa funzionalità nel core di Discourse.
L’output Markdown viene generato dall’HTML renderizzato (“cotto”) dei post, preservando i contenuti visualizzati dai lettori, inclusi i link espansi e la formattazione elaborata. Gli elementi specifici di Discourse, come citazioni, onebox, blocchi di codice, sondaggi e sezioni comprimibili, vengono convertiti nuovamente in Markdown. Le risposte ai topic includono metadati e link di paginazione, e i corpi dei post convertiti vengono memorizzati nella cache utilizzando un digest del contenuto, in modo che le modifiche producano un output aggiornato.
I client possono richiedere esplicitamente il Markdown tramite URL .md oppure inviando un header Accept: text/markdown. La negoziazione rispetta i valori di qualità e seleziona il Markdown quando è preferito rispetto a HTML e JSON; le richieste esplicite .md mantengono i loro formati. Le pagine HTML supportate pubblicizzano il loro equivalente Markdown tramite un header HTTP Link e un elemento <link rel="alternate">.
Poiché sto attualmente utilizzando il plugin originale Discourse-to-Markdown, devo disattivarlo e rimuoverlo per evitare output in conflitto? Vi prego di consigliarmi.
Una domanda: per chi utilizza il proxy di Cloudflare, sembra esserci un conflitto tra la funzione del core e il loro strumento di conversione. La domanda è: se mi trovo dietro il proxy, dato che la funzione è riservata agli abbonati, impediranno la conversione dell’header da HTML a .md, oppure, poiché il client supporta la conversione, questa avviene indipendentemente da ciò?
Sì. Se il plugin rimane abilitato, sostituisce alcuni degli endpoint principali, quindi consigliamo di disattivarlo/rimuoverlo per utilizzare la funzionalità ora presente nel core.
Non sono molto familiare con la funzione di Cloudflare, ma da ciò che posso capire, intercetta la richiesta Accept text/markdown prima che raggiunga il server, converte l’html e poi la serve. Quindi, sembra che quella funzione sovrascriverebbe quella di Discourse, se/quando si utilizza Cloudflare.
Sarebbe sovrascritto se abilitato, giusto? Non ho trovato sul loro blog alcuna informazione su se impediscono all’origine stessa di impostare questo header.
Non lo so con certezza, ma l’opzione più semplice è testare su un sito live e confrontare l’output con quello che restituisce meta. Ci saranno differenze nel contenuto incluso. Se la risposta che ottieni è la stessa con o senza la funzione di Cloudflare, allora sta rispettando il Markdown restituito da Discourse core.
X-Discourse-Crawler-View: true (indica che Discourse mette a disposizione anche una versione pulita in .md / Markdown nativo per crawler e lettori).
L’header Link che indica la versione alternativa: Link: <https://segredin.com/t/conselhos-duvidosos/22054.md>; rel="alternate"; type="text/markdown"
Restituisce Vary: Accept dall’origine indipendentemente dalle funzioni esterne a livello di DNS.
Se la richiesta viene effettuata senza il suffisso .json, verrà restituito il .md come conversione predefinita.
HTTP/1.1 200 OK
Content-Type: text/markdown
Vary: Accept
Ho avuto dei dubbi perché ho ricevuto 123.000 richieste da Claude e la maggior parte, da quando ho aggiornato Discourse con questa funzione del core, non è aumentata in modo vertiginoso. Continuerò a monitorare la situazione nelle prossime settimane.
Grazie, ero confuso perché ho provato prima su un elenco di argomenti filtrato per categoria e tag e non ha funzionato. Tendo a scegliere esempi poco adatti per i test.
Core prevede che i blocchi discourse-post-event abbiano una rappresentazione Markdown dedicata, allo stesso modo in cui già avviene per sondaggi, citazioni, onebox e sezioni comprimibili? Dal punto di vista tecnico, aggiungerne una a CookedProcessor sembra piuttosto fattibile: rilevare div.discourse-post-event, leggere i suoi attributi data-* e sostituirlo con un blocco Markdown preservato prima del passaggio generico di ReverseMarkdown.