Мы настроили плагин 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), с чистым текстом в формате text/plain и отдельным text/html
На самом деле, так сейчас и работают уведомления Discourse по электронной почте. Если вы посмотрите на «оригинал» уведомления Discourse по электронной почте, то увидите, что там есть текстовая и HTML-версия.
Похоже, вы имеете в виду следующее, хотя я всё ещё не до конца уверен в этом: вы получаете HTML-сущности в текстовой версии уведомлений Discourse по электронной почте, в результате чего в теле письма видны сами HTML-сущности при просмотре в почтовом клиенте, не поддерживающем HTML. Не так ли? Не могли бы вы прислать скриншот этого из почтового клиента (без поддержки HTML)?
Если это так, то это проблема, специфичная для генерации и форматирования контента в письмах Discourse, и её лучше вынести в более узкоспециализированную тему в разделе Support или Contribute > 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 будет использовать её как необязательную настройку.