Discourse unterstützt jetzt native Markdown-Endpunkte, wodurch es für KI-Tools und andere Clients einfacher wird, Foreninhalt zu lesen, ohne vollständige HTML-Seiten parsen zu müssen.
Diese Funktion wird über das System „Upcoming Changes“ standardmäßig auf allen gehosteten Sites aktiviert. Administratoren, die sich dagegen entscheiden möchten, können dies tun, indem sie die Upcoming Change enable_markdown_endpoints unter /admin/config/upcoming-changes?changeNamesFilter=enable_markdown_endpoints deaktivieren:
Vielen Dank an @benword für die Erstellung des ursprünglichen Discourse to Markdown Plugins, der den Vorläufer dieser Funktion im Discourse-Kern bildete.
Die Markdown-Ausgabe wird aus dem gerenderten („cooked“) HTML von Beiträgen generiert und erhält dabei den Inhalt bei, den Leser sehen, einschließlich expandierter Links und verarbeiteter Formatierungen. Discourse-spezifische Elemente wie Zitate, Oneboxes, Codeblöcke, Umfragen und einklappbare Abschnitte werden in Markdown zurückgewandelt. Themenantworten enthalten Metadaten und Paginierungslinks, und umgewandelte Beitragskörper werden mit einer Inhaltszusammenfassung (Content Digest) zwischengespeichert, sodass Bearbeitungen eine frische Ausgabe erzeugen.
Clients können Markdown explizit über .md-URLs oder durch Senden eines Accept: text/markdown-Headers anfordern. Die Verhandlung berücksichtigt Qualitätswerte und wählt Markdown, wenn es gegenüber HTML und JSON bevorzugt wird; explizite .md-Anforderungen behalten ihre Formate bei. Unterstützte HTML-Seiten bewerben ihr Markdown-Äquivalent über einen HTTP Link-Header und ein <link rel="alternate">-Element.
Da ich derzeit das ursprüngliche Discourse-to-Markdown-Plugin verwende, muss ich es deaktivieren und entfernen, um widersprüchliche Ausgaben zu vermeiden? Bitte um Rat.
Eine Frage: Bei der Nutzung des Cloudflare-Proxys scheint es einen Konflikt zwischen der Kernfunktion und ihrem Werkzeug zur Konvertierung zu geben. Die Frage lautet: Wenn ich mich hinter dem Proxy befinde, wird die Konvertierung des Headers von HTML in .md aufgrund der Funktion für Abonnenten blockiert, oder erfolgt sie unabhängig davon, da der Client die Konvertierung unterstützt?
Ja. Wenn das Plugin aktiviert bleibt, ersetzt es einige der Kern-Endpunkte. Wir empfehlen daher, es zu deaktivieren bzw. zu deinstallieren, um die jetzt in der Kernversion verfügbare Funktionalität zu nutzen.
/categories.md und /tags.md werden zusätzlich als Verzeichnisse unterstützt. Routendefinitionen
Ich kenne die Cloudflare-Funktion nicht im Detail, aber soweit ich das beurteilen kann, fängt sie die Accept text/markdown-Anfrage ab, bevor sie den Server erreicht, konvertiert das HTML und liefert es dann aus. Es scheint also so, als würde diese Funktion die von Discourse überschreiben, wenn Cloudflare verwendet wird.
Es würde überschrieben, wenn es aktiviert ist, richtig? Ich habe in ihrem Blog keine Informationen gefunden, ob sie verhindern, dass der eigene Ursprung diesen Header bereitstellt.
Ich kann das nicht mit Sicherheit sagen. Die einfachste Option ist, es auf einer Live-Seite zu testen und die Ausgabe mit dem zu vergleichen, was Meta ausgibt. Es wird Unterschiede in den enthaltenen Inhalten geben. Wenn die Antwort, die du erhältst, mit oder ohne die Cloudflare-Funktion gleich ist, dann wird das von Discourse Core zurückgegebene Markdown respektiert.
X-Discourse-Crawler-View: true (was zeigt, dass Discourse auch eine saubere .md-Version / natives Markdown für Crawler und Reader bereitstellt).
Der Header Link, der die alternative Version angibt: Link: <https://segredin.com/t/conselhos-duvidosos/22054.md>; rel="alternate"; type="text/markdown"
Gibt Vary: Accept von der Quelle zurück, unabhängig von externen Funktionen auf DNS-Ebene.
Wenn die Anfrage ohne das .json-Suffix gestellt wird, wird standardmäßig die .md-Version als Konvertierung zurückgegeben.
HTTP/1.1 200 OK
Content-Type: text/markdown
Vary: Accept
Ich war mir unsicher, da ich 123.000 Anfragen von Claude erhalten habe und die meisten, seit ich Discourse mit dieser Kernfunktion aktualisiert habe, nicht steil angestiegen sind. Ich werde dies in den kommenden Wochen weiter beobachten.
Danke, ich war verwirrt, weil ich es zuerst in einer Themenliste ausprobiert habe, die nach einer Kategorie und einem Tag gefiltert war, und es dort nicht funktioniert hat. Ich wähle oft schlechte Beispiele für Tests.
Warum hast du /new und /unread einbezogen, aber nicht /unseen?
Soll discourse-post-event-Blöcke in der Core-Instanz eine eigene Markdown-Darstellung erhalten, so wie es bereits bei Umfragen, Zitaten, Oneboxes und einklappbaren Abschnitten der Fall ist? Technisch gesehen ist die Hinzufügung einer solchen Darstellung in CookedProcessor durchaus machbar: div.discourse-post-event erkennen, dessen data-*-Attribute auslesen und es vor dem generischen ReverseMarkdown-Durchlauf durch einen beibehaltenen Markdown-Block ersetzen.
Es handelt sich tatsächlich um eine bevorstehende Änderung. Du musst zu /admin/config/upcoming-changes?changeNamesFilter=enable_markdown_endpoints navigieren.
Ich habe es deaktiviert, aber es steht dort, dass ich in Kürze keine Wahl mehr treffen kann. Ich will Scrapern die Sache nicht zu leicht machen, und diese Ansicht umgeht einige Methoden, die ich verwende, um Bots zu finden.
