Discourse supporta ora gli endpoint Markdown nativi, rendendo più semplice per gli strumenti di IA 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 “Modifiche in arrivo”. Gli amministratori che desiderano disattivarla possono farlo disabilitando la modifica in arrivo enable_markdown_endpoints in /admin/config/upcoming-changes?changeNamesFilter=enable_markdown_endpoints:
Un grande ringraziamento a @benword per aver creato l’originale plugin Discourse to Markdown, che è stato il precursore di questa funzionalità nel nucleo 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 riconvertiti 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 dei contenuti in modo che le modifiche producano un output aggiornato.
I client possono richiedere esplicitamente il Markdown tramite URL .md o 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.
L’ho disattivata, ma mi dice che non potrò selezionarla a breve. Non voglio rendere le cose troppo facili per i crawler, e quella vista elude alcuni dei metodi che uso per individuare i bot.
Una piccola osservazione, nel caso fosse utile: un mese dopo che la funzionalità si è attivata qui, markdown-endpoint:cooked:* conteneva circa un milione di chiavi, l’87% dei nostri chiavi Redis (circa 570 MB). Quasi tutte provenivano da bot che recuperavano pagine in .md, con ogni post memorizzato nella cache per una settimana. Sembra davvero tanto Redis per una sola funzionalità.
Questo mi incuriosisce riguardo all’altro lato dell’equazione. Qualcuno ha notato visitatori reali tornare grazie a essa? In tal caso, sarebbe facile decidere di riattivarla.
