Мы настроили плагин WordPress для публикации полных тем в категорию объявлений на нашем форуме. Это работает довольно хорошо, но электронные письма, отправляемые Discourse, помечены как Content-Type: text/plain; charset=UTF-8.
Насколько я понимаю, это технически верно, так как ожидаемый формат — Markdown, который по сути является простым текстом. Но, разумеется, Markdown также (к лучшему или к худшему) допускает использование HTML: «HTML тоже работает, без проблем!».
При этом посты, поступающие из WordPress, содержат множество HTML-тегов.
Как другие пользователи справляются с этой проблемой? Есть ли способ сделать так, чтобы публикации в Discourse представляли собой разумный для человека Markdown? Или можно принудительно установить тип контента HTML для писем, генерируемых в этой категории? Или, может быть, есть какие-то другие идеи? Спасибо!
Да, извините. Под «сообщениями» я имел в виду «электронные письма». А под «это» я имел в виду Discourse, а не плагин для WordPress. Я отредактирую первый пост, чтобы это стало понятнее.
По моему представлению, идеальным вариантом было бы, чтобы электронные письма были многосоставными: с рендерингом markdown в виде чистого текста text/plain и отдельной версией text/html. Но я даже не уверен, как это могло бы работать.
Извините, еще раз уточню: вы поднимаете этот вопрос потому, что в электронных уведомлениях о сообщениях Discourse, содержащих HTML (например, сообщениях, связанных с постами WordPress в вашей категории объявлений), некорректно отображаются HTML-сущности? Если да, не могли бы вы привести пример?
Я настаиваю на этом, потому что генерация электронных уведомлений в Discourse полностью отделена от всего, что связано с плагином WordPress. У электронных уведомлений есть собственный конвейер, и существует множество способов, при которых в сообщении Discourse могут появиться HTML-сущности; пост из WordPress — лишь один из них.
Другими словами, наличие HTML в сообщении Discourse — это отдельная проблема от того, что содержат уведомления об этом сообщении и как они закодированы. Понимание конкретной проблемы, с которой вы столкнулись / которую поднимаете, поможет привлечь к ней внимание нужных специалистов.
Возможно, я что-то неправильно понимаю, но вот что, как мне кажется, происходит:
Пост в WordPress публикуется.
Плагин реагирует на это и создаёт пост в Discourse.
Все посты в Discourse написаны на Markdown, но в данном случае пост, пришедший из WordPress через плагин, представляет собой нагромождение HTML-кода (что вполне допустимо в Markdown).
Пользователи, подписанные на уведомления по электронной почте, получают письмо с этим текстом — и он выглядит как хаос из HTML-тегов.
Я понимаю, что кто-то мог бы вручную создать пост в Discourse с большим количеством HTML-кода таким же образом, но на практике это обычно не является проблемой (а если и станет, то её можно решить вежливым «эй, может, не стоит?»).
Выглядит так же, как в редакторе Discourse при редактировании поста, так и при отправке:
<small>Originally published at: https://communityblog.fedoraproject.org/cpe-hiring-a-software-engineer/
</small><br><p>Группа Community Platform Engineering, или CPE, — это команда Red Hat, объединяющая ИТ-инфраструктуру и инженерные процессы выпуска Fedora и CentOS. В настоящее время у нас открыта вакансия <a href="https://global-redhat.icims.com/jobs/96157/software-engineer/job?mobile=true&width=412&height=732&bga=true&needsRedirect=false&jan1offset=-480&jun1offset=-420">инженера-программиста в Индии</a>.</p>
<h2>О роли</h2>
<p>Мы ищем <a href="https://global-redhat.icims.com/jobs/96157/software-engineer/job?mobile=true&width=412&height=732&bga=true&needsRedirect=false&jan1offset=-480&jun1offset=-420">новых специалистов</a> для работы полный рабочий день над проектом Fedora, в основном в нашей группе Release Engineering. Вы будете работать над инфраструктурой, которая собирает и распространяет релизные артефакты и обновления Fedora Linux. Эта роль идеально подходит для тех, у кого есть опыт или интерес к инженерии релизов.</p>
<h2>О CPE</h2>
<p>Наша цель — поддерживать работу и обслуживание основных серверов и сервисов, выпускать релизы и выполнять другие стратегические задачи, требующие больше времени, чем могут выделить волонтёры.</p>
<p>Подробнее см. в <a href="https://docs.fedoraproject.org/en-US/cpe/">нашей документации</a>. Мы с нетерпением ждём возможности познакомиться с вами и, надеемся, вскоре начать совместную работу!</p>
Хорошо, я отвечу на поднятые вами вопросы по отдельности. Я понимаю, почему вы их связываете, но надеюсь, вы увидите, почему это разные проблемы.
HTML-сущности в текстовых письмах
было бы лучше всего, если бы письма были multipart-формата с чистым текстовым рендерингом markdown text/plain и отдельным text/html
На самом деле именно так сейчас работают уведомления по электронной почте в Discourse. Если вы посмотрите на «оригинал» уведомления по электронной почте в Discourse, то увидите, что там есть текстовая версия и HTML-версия.
Кажется, вы говорите, хотя я пока не до конца уверен в этом, что в текстовой версии уведомлений по электронной почте в Discourse вы получаете HTML-сущности, в результате чего в теле письма, при просмотре его в почтовом клиенте, не поддерживающем HTML, вы видите сами HTML-сущности. Так ли это? Можете ли вы предоставить скриншот этого из почтового клиента (не поддерживающего HTML)?
Если это так, то это проблема, специфичная для генерации и форматирования содержимого писем в Discourse, и лучше вынести её в отдельную, более целенаправленную тему в Support или bug.
HTML в постах Discourse
Вы поднимаете здесь актуальный вопрос, но с технической точки зрения дело в том, как Discourse в целом подходит к импортируемому контенту. Текущее значение по умолчанию для импортируемого контента — HTML, а не markdown.
Другие примеры, где это можно увидеть, — это плагин RSS Polling, который, как и плагин WP Discourse, импортирует HTML в содержимое поста. Обратите также внимание, что настройка сайта embed support markdown по умолчанию выключена, как и все остальные настройки сайта, касающиеся встроенного HTML в постах (например, allowed embed selectors).
Я частично гадаю, но наиболее вероятная причина (или причины) принятия этого стратегического решения в ранние дни работы Discourse с импортируемым контентом — это сочетание простоты и точности, то есть преобразование из HTML в markdown будет неполным. Есть одно ключевое исключение, о котором я упомяну ниже.
Плагин WP Discourse мог бы попытаться преобразовать HTML-код постов WordPress в markdown перед отправкой их в Discourse. Да, существуют библиотеки на PHP, которые конвертируют HTML в markdown, но при конвертации языка разметки, особенно учитывая различные варианты markdown, это никогда не бывает так просто.
Более того, попытка плагина WP Discourse обработать конвертацию была бы ошибочной, учитывая, что в Discourse уже существует собственный конвертер HtmlToMarkdown. В настоящее время этот конвертер обрабатывает преобразование HTML в markdown в письмах, импортируемых в Discourse. Если HTML-код постов из WordPress должен быть конвертирован в markdown Discourse, это должно быть обработано этим конвертером.
В настоящее время плагин WP Discourse использует API Discourse для публикации постов, то есть конечную точку /posts. Таким образом, по сути, вы говорите, что хотите добавить поддержку конвертера HtmlToMarkdown в конечную точку Discourse /posts (например, в качестве необязательного параметра запроса). Вы можете выступить за это, и если это будет реализовано, плагин WP Discourse примет это как необязательную настройку.