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 zu parsen.
Diese Funktion wird standardmäßig auf allen gehosteten Sites über das System „Upcoming Changes“ aktiviert. Administratoren, die sich dagegen entscheiden möchten, können dies tun, indem sie die Site-Einstellung enable_markdown_endpoints deaktivieren.
Vielen Dank an @benword für die Erstellung des ursprünglichen Discourse to Markdown-Plugins, das die Vorläufer dieser Funktion im Discourse-Kern war.
Die Markdown-Ausgabe wird aus dem gerenderten („gekochten“) HTML der Beiträge generiert und bewahrt den Inhalt, den Leser sehen, einschließlich expandierter Links und verarbeiteter Formatierungen. Discourse-spezifische Elemente wie Zitate, Oneboxes, Codeblöcke, Umfragen und aufklappbare Abschnitte werden in Markdown zurückgewandelt. Themenantworten enthalten Metadaten und Paginierungslinks, und die konvertierten Beitragskörper werden mit einer Inhalts-Verdauung (Content Digest) zwischengespeichert, sodass Bearbeitungen eine neue Ausgabe erzeugen.
Clients können Markdown explizit über .md-URLs anfordern oder durch das Senden eines Accept: text/markdown-Headers. Die Verhandlung respektiert Qualitätswerte und wählt Markdown, wenn es HTML und JSON gegenüber bevorzugt wird; explizite .md-Anfragen 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.