Discourse теперь поддерживает нативные Markdown-эндпоинты, что упрощает чтение контента форумов для ИИ-инструментов и других клиентов без необходимости парсинга полных HTML-страниц.
Эта функция будет включена по умолчанию на всех хостинговых сайтах через систему Upcoming Changes. Администраторы, желающие отказаться от её использования, могут сделать это, отключив предстоящее изменение enable_markdown_endpoints на странице /admin/config/upcoming-changes?changeNamesFilter=enable_markdown_endpoints:
Огромная благодарность @benword за создание оригинального плагина Discourse to Markdown, который стал предшественником этой функции в ядре Discourse.
Markdown-вывод генерируется из отрендеренного («cooked») HTML постов, сохраняя контент, видимый читателям, включая раскрытые ссылки и обработанное форматирование. Специфические элементы Discourse, такие как цитаты, oneboxes, блоки кода, опросы и сворачиваемые секции, преобразуются обратно в Markdown. Ответы тем содержат метаданные и ссылки на пагинацию, а преобразованные тела постов кэшируются с использованием контрольной суммы содержимого, чтобы при редактировании формировался новый вывод.
Клиенты могут явно запрашивать Markdown с помощью URL-адресов с расширением .md или путем отправки заголовка Accept: text/markdown. Переговоры учитывают значения качества (quality values) и выбирают Markdown, если он предпочтительнее HTML и JSON; явные запросы .md сохраняют свои форматы. Поддерживаемые HTML-страницы указывают на свой Markdown-эквивалент с помощью HTTP-заголовка Link и элемента <link rel="alternate">.
Поскольку в настоящее время я использую оригинальный плагин Discourse-to-Markdown, нужно ли мне отключить и удалить его, чтобы избежать конфликтующих результатов? Прошу дать совет.
Один вопрос: для тех, кто использует прокси Cloudflare, кажется, возникает конфликт между функцией ядра и их инструментом конвертации. Вопрос в том: если я нахожусь за прокси, то из-за того, что эта функция доступна только подписчикам, они будут блокировать конвертацию заголовка из HTML в .md, или, поскольку клиент поддерживает конвертацию, она происходит независимо от этого?
Да. Если плагин останется включенным, он заменяет некоторые из основных конечных точек, поэтому мы рекомендуем отключить/удалить его, чтобы использовать функциональность, теперь встроенную в ядро.
В настоящее время поддерживаются следующие:
Поддерживается
Примеры
Основные списки
/latest.md, /hot.md, /top.md
Персональные списки, требующие аутентификации
/new.md, /unread.md
Списки по умолчанию для категорий/подкатегорий
/c/support/6.md, /c/parent/child/12.md
Списки по одному тегу
/tag/example.md, /tag/example/123.md
Дополнительно /categories.md и /tags.md поддерживаются как каталоги. Определения маршрутов
Я не очень хорошо знаком с этой функцией Cloudflare, но насколько я могу судить, она перехватывает запрос Accept text/markdown до того, как он достигнет сервера, преобразует HTML и затем отдает его. Таким образом, похоже, что эта функция будет переопределять аналогичную функцию Discourse, если используется Cloudflare.
Если это включено, он будет переопределяться, верно? Я не нашёл в их блоге никакой информации о том, препятствуют ли они самой отправке этого заголовка с источника.
Я не могу сказать наверняка, но самый простой вариант — протестировать на живом сайте и сравнить вывод с тем, что выводит meta. Будут различия в том, какой контент включается. Если полученный вами ответ одинаков с включённой и выключенной функцией Cloudflare, значит, она учитывает Markdown, возвращаемый ядром Discourse.
X-Discourse-Crawler-View: true (показывает, что Discourse также предоставляет чистую версию в формате .md / нативный Markdown для веб-сканеров и читалок).
Заголовок Link, указывающий на альтернативную версию: Link: <https://segredin.com/t/conselhos-duvidosos/22054.md>; rel="alternate"; type="text/markdown"
Возвращает Vary: Accept от источника независимо от внешних функций на уровне DNS.
Если клиент выберет сделать запрос без .json, будет возвращена версия .md как стандартное преобразование.
HTTP/1.1 200 OK
Content-Type: text/markdown
Vary: Accept
Я сомневался, потому что получил 123 тысячи запросов от Claude, и большинство из них, с тех пор как я обновил Discourse с этой функцией ядра, не выросли в геометрической прогрессии. Буду наблюдать за этим в ближайшие недели.
Спасибо, я запутался, потому что сначала попробовал на списке тем, отфильтрованном по категории и тегу, и это не сработало. Я склонен выбирать неудачные примеры для тестирования.
Предполагает ли ядро, что блоки discourse-post-event должны иметь собственное представление в формате Markdown, так же как уже сейчас это реализовано для опросов, цитат, onebox-блоков и сворачиваемых секций? Технически, добавление такой функциональности в CookedProcessor выглядит вполне осуществимым: обнаружить div.discourse-post-event, прочитать его атрибуты data-* и заменить на сохранённый Markdown-блок до общего прохода ReverseMarkdown.
Я это отключил, но система говорит, что скоро я не смогу выбирать. Я не хочу делать всё слишком простым для скраперов, а этот режим обходит некоторые методы, которые я использую для поиска ботов.
Небольшое наблюдение, на случай если это будет полезно: через месяц после того, как эта функция сама включилась здесь, markdown-endpoint:cooked:* содержал около миллиона ключей, составляя 87% нашего пространства ключей Redis (~570 МБ). Почти всё это было связано с ботами, загружающими страницы .md, где каждый пост кэшировался на неделю. Кажется, что это слишком много ресурсов Redis для одной функции.
Это заставляет меня задуматься о другой стороне вопроса. Видел ли кто-нибудь реальных посетителей, возвращающихся благодаря этой функции? Если да, то решение включить её обратно было бы очевидным.
