현재 워드프레스 플러그인을 설정하여 전체 주제를 포럼의 공지사항 카테고리에 게시하도록 하고 있습니다. 이 방식은 꽤 잘 작동하지만, 디스커스가 보내는 이메일 메시지는 Content-Type: text/plain; charset=UTF-8으로 표시됩니다.
제 이해로는, 기대되는 형식이 마크다운이고 이는 일종의 평문(plain-text)이므로 기술적으로는 맞는 말입니다. 하지만 물론, 마크다운은 좋든 나쁘든 "HTML도 유효하다, yolo!"를 포함하고 있죠.
사실, 워드프레스에서 넘어오는 게시글들은 HTML 덩어리입니다.
다른 분들은 이 문제를 어떻게 해결하고 계신가요? 디스커스에 게시된 버전을 결국에는 인간이 읽기 합리적인 마크다운으로 만들 수 있는 방법이 있을까요? 아니면, 이 카테고리에서 생성되는 이메일에 대해 HTML 콘텐츠 타입을 강제할 수 있는 방법이 있을까요? 아니면… 다른 아이디어가 전혀 없으신가요? 감사합니다!
@mattdm 님, 확인 차 여쭤볼게요.
여기서 말하는 "메시지"는 공지 카테고리에 새 게시물이 올라왔을 때 Discourse에서 받는 이메일 알림을 말씀하시는 건가요?
여기서 해결하려는 구체적인 사용자 불편 사항이 무엇인지 이해하려고 합니다.
네, 죄송합니다. 'messages’라고 한 것은 '이메일 메시지’를 의미했습니다. 그리고 'it’은 WordPress 플러그인이 아니라 Discourse를 가리킨 것입니다. 이를 명확히 하기 위해 첫 번째 게시물을 수정하겠습니다.
내 상상으로는, 이메일 메시지가 멀티파트 형식이라면 가장 좋을 것 같아요. 깔끔한 텍스트로 렌더링된 마크다운 text/plain과 별도의 text/html을 포함하는 형태 말이죠. 하지만 그게 실제로 어떻게 작동하는지조차 확신이 서지 않습니다.
죄송합니다. 다시 한 번 명확히 하기 위해 질문드리는데, HTML(예: 공지 카테고리에서 WordPress 게시물로 연결된 게시물)을 포함하는 Discourse 게시물의 이메일 알림에 HTML 엔티티가 잘못 포함되어 있기 때문에 이 문제를 제기하신 건가요? 그렇다면 예시를 공유해 주실 수 있을까요?
이 문제를 자세히 여쭤보는 이유는, Discourse에서 이메일 알림이 생성되는 과정이 WordPress 플러그인과 관련된 것과 상당히 별개이기 때문입니다. 이메일 알림은 자체 파이프라인을 가지고 있으며, Discourse 게시물에 HTML 엔티티가 포함되는 방법은 여러 가지가 있습니다. WordPress에서 가져온 게시물이 그중 하나일 뿐입니다.
즉, Discourse 게시물에 HTML이 포함되어 있다는 사실은, 해당 게시물에 대한 이메일 알림의 내용과 인코딩 방식과는 별개의 문제입니다. 겪고 계시거나 제기하시는 구체적인 문제를 이해하는 것이, 해당 문제에 적절한 관심과 해결책을 마련하는 데 도움이 될 것입니다.
제가 상황을 잘못 이해하고 있는 것일 수도 있지만, 제 생각에는 다음과 같은 일이 일어나고 있습니다:
누군가 수동으로 Discourse 게시글에 HTML을 대량으로 넣을 수 있다는 점은 인지하고 있습니다. 하지만 실무적으로는 보통 문제가 되지 않습니다(만약 문제가 된다면, "제발 그렇게 하지 말아 주시겠어요?"라는 정중한 요청으로 대부분 해결될 수 있을 것입니다).
이 설명이 명확히 전달되었기를 바랍니다.
예를 들어, 이 게시글
Discourse에서 게시글을 수정하러 들어가거나, 메일로 발송되었을 때 모두 다음과 같은 모습입니다:
<small>Originally published at: https://communityblog.fedoraproject.org/cpe-hiring-a-software-engineer/
</small><br><p>The Community Platform Engineering group, or CPE for short, is the Red Hat team combining IT and release engineering for Fedora and CentOS. We currently have a position open for a <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">software engineer in India</a>.</p>
<h2>About the role</h2>
<p>We are <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">hiring new talent</a> to come work full time on Fedora, primarily as part of our Release Engineering group. You’ll get to work on the infrastructure that builds and ships the Fedora Linux release artifacts and updates. This role is perfect for anyone with experience or interest in Release Engineering.</p>
<h2>About CPE</h2>
<p>Our goal is to keep core servers and services running and maintained, build releases, and perform other strategic tasks that need more dedicated time than volunteers can give.</p>
<p>See <a href="https://docs.fedoraproject.org/en-US/cpe/">our docs</a> for more information. We are looking forward to meeting you and hopefully working with you soon!</p>
… 이는 매우 유용하지 않습니다.
좋습니다. 여기서 제기하신 문제들을 각각 따로 답변드리겠습니다. 왜 이 문제들을 연결 지으시는지 이해는 하지만, 왜 별개의 문제인지 이해해 주시길 바랍니다.
가장 좋은 방법은 이메일 메시지가 다중 부분(multi-part) 구조로, 마크다운을 렌더링한 깔끔한
text/plain버전과 별도의text/html버전으로 구성되는 것입니다.
사실 Discourse의 이메일 알림은 현재 이렇게 작동합니다. Discourse 이메일 알림의 "원본(original)"을 확인해 보시면 텍스트 버전과 HTML 버전이 모두 포함되어 있음을 보실 수 있습니다.
말씀하시는 내용으로 짐작하건대(아직 100% 명확하지는 않지만), Discourse 이메일 알림의 일반 텍스트 버전에서 HTML 엔티티가 표시되고 있다는 것일 텐데, 그 결과 HTML을 지원하지 않는 이메일 클라이언트로 확인하면 이메일 본문에 실제 HTML 엔티티가 그대로 보인다는 말씀이신가요? 그렇다면 HTML을 지원하지 않는 이메일 클라이언트에서 해당 현상을 보여주는 스크린샷을 공유해 주실 수 있을까요?
만약 그렇다면 이는 Discourse 이메일 콘텐츠 생성 및 포맷팅에 특화된 문제이므로, Support 또는 Contribute > Bug 게시판에서 더 구체적으로 다룰 수 있는 별도 토픽으로 분리하는 것이 가장 좋습니다.
여기서 제기하신 문제는 관련성이 높지만, 기술적인 관점에서는 질문의 핵심이 Discourse가 가져온(imported) 콘텐츠를 어떻게 다루는가에 있습니다. 현재 가져온 콘텐츠의 기본 형식은 마크다운이 아닌 HTML입니다.
이 현상을 볼 수 있는 다른 맥락으로는 RSS Polling 플러그인이 있습니다. 이 플러그인도 WP Discourse 플러그인과 마찬가지로 HTML을 게시물 콘텐츠로 가져옵니다. 또한 embed support markdown 사이트 설정은 기본적으로 꺼져 있으며, 게시물 내 임베드된 HTML을 다루는 다른 사이트 설정들(예: allowed embed selectors)도 마찬가지입니다.
여기서는 일부 추측을 섞어 말씀드리지만, Discourse 초기에 가져온 콘텐츠를 다루는 이 전략적 결정이 내려진 가장 그럴듯한 이유는 단순성과 충실성(fidelity)의 조합일 것입니다. 즉, HTML에서 마크다운으로의 변환은 완벽할 수 없기 때문입니다. 아래에서 언급하겠지만, 이에 대한 중요한 예외가 하나 있습니다.
WP Discourse 플러그인은 WordPress 게시물의 HTML을 Discourse로 보내기 전에 마크다운으로 변환하는 시도를 할 수 있습니다. HTML을 마크다운으로 변환하는 기존 PHP 라이브러리가 있긴 하지만, 특히 마크다운의 다양한 변형(flavours)을 고려할 때 마크업 언어 간 변환은 결코 그렇게 간단하지 않습니다.
실제로 WP Discourse 플러그인이 이 변환을 처리하려 하는 것은 오히려 잘못된 접근일 수 있습니다. Discourse에는 이미 커스텀 HtmlToMarkdown 변환기가 존재하기 때문입니다. 현재 이 변환기는 Discourse로 가져온 이메일의 HTML을 마크다운으로 변환하는 역할을 담당합니다. WordPress 게시물의 HTML을 Discourse 마크다운으로 변환하려면 이 변환기를 통해 처리되어야 합니다.
현재 WP Discourse 플러그인은 게시물을 게시하기 위해 Discourse API, 즉 /posts 엔드포인트를 사용합니다. 따라서 사실상 말씀하시는 내용은 Discourse의 /posts 엔드포인트에 HtmlToMarkdown 변환기 지원(예: 선택적 쿼리 파라미터로)을 추가해 달라는 것입니다. 이에 대해 주장(advocate)하실 수 있으며, 만약 구현된다면 WP Discourse 플러그인은 이를 선택적 설정으로 채택하게 될 것입니다.