네, 그 방향으로 완전히 나아가려면 Discourse에서 콘텐츠를 편집할 수 없는 것과 완전한 HTML 무결성 사이의 트레이드오프를 감수해야 합니다.
수입된 HTML 게시물에서 img 태그에만 이 방식을 적용하면 중간 지점을 찾을 수 있을 것 같다고 생각했습니다.
하지만 지금은 제 생각이 틀렸을 수도 있다는 느낌이 듭니다. 선택적으로 이를 적용하려면 게시물 처리 과정의 여러 부분에 변경 사항이 필요합니다.
2개의 좋아요
네, 이 옵션이 아마도 가장 좋을 것 같습니다. 2020년 6월에 작업을 시작하긴 했지만, 예상보다 많은 작업량이었고 다른 프로젝트로 넘어가야 했습니다. <img 태그에서 upload:// URL을 허용하기 위한 몇 가지 접근법을 시도해 보았는데… 어느 쪽도 완벽하지는 않았습니다. 제 노트에 적어둔 내용입니다:
구현 1:
마크다운 파이프라인에서 각 html_block의 내용을 파싱하고(이를 위해 xss.js 라이브러리를 약간 악용하는 방식) upload:// src 속성을 가진 이미지 태그를 처리합니다.
장점: 전부 마크다운 파이프라인 내에서 처리되며, html_block 토큰에 대해서만 이 처리를 수행합니다.
단점: xss.js 세리나이저를 약간 잘못 사용하고 있습니다. 또한 완벽한 HTML5 파서일 수 없습니다.
이 옵션은 서버에서 표준 준수 JavaScript DOM 구현(예: jsdom)을 사용하여 개선할 수 있지만, 그건 꽤 무거워 보입니다.
구현 2:
마크다운 파이프라인 전체에서 upload:// src 속성을 허용한 후 나중에 교체합니다. 클라이언트에서는 실제로 꽤 간단합니다 - 이미 쿠킹(cooking) 후 upload:// URL을 비동기적으로 교체하고 있었기 때문입니다. 서버에서는 Nokogiri를 사용하여 추가적인 처리 단계를 수행합니다.
장점: 파서가 HTML5 표준에 준수합니다.
단점: 클라이언트/서버 구현이 다르고, 파이프라인이 약간 더 복잡해집니다.
옵션 2가 아마도 나아갈 방향일 것 같습니다. 그러면 <img 태그를 유지하면서 마크다운으로 교체하지 않도록 pull_hotlinked_images 작업을 업데이트해야 합니다. 곧 이 작업에 다시 집중할 시간을 찾을 수 있기를 바랍니다 
4개의 좋아요
여기서 왜 이런 복잡함이 발생하는지 정말 이해가 안 됩니다. 분명히 HTML 이미지 태그가 마크다운으로 대체되고 있잖아요 — 예를 들어 처럼요. 왜 ! 앞에 캐리지 리턴 두 개를 포함하도록 하지 않는 걸까요? 그러면 이미지가 올바르게 렌더링되고, 이미지 업로드 기능이 작동하여 깨진 이미지와 크로스 사이트 문제를 방지할 수 있을 텐데요.
실제 이론적이지 않은 상황에서 그 공백이 문제를 일으킬 수 있는 경우가 있을까요? 그런 문제가 현재 플러그인의 "이미지가 항상 깨져 있다"는 상태보다 더 나쁘다고 볼 수 있을까요?
@david님, "콘텐츠의 무결성을 유지하는 것이 우리에게 핵심"이기 때문에 "줄바꿈 솔루션은 아마도 이루어지지 않을 것"이라고 언급하셨습니다. 하지만 콘텐츠는 애초에 태그를 삽입하는 것만으로 이미 변경되고 있습니다. 제가… 정말로 이게 어떻게 더 나은 것인지 이해가 되지 않습니다.
지금 모든 사용자가 워드프레스 게시물에 이미지를 포함시킬 때마다 이미지가 깨져서 돌아오고, 저는 "이미지가 깨졌다"는 댓글을 자주 처리해야 하며, 그 뒤에 "그래, 디스커스가 별로라서 그렇다"는 답변이 자주 따라옵니다. 이 두 가지 상황을 모두 피하고 싶습니다.
“이미지 다운로드 안 함” 설정이 대안이 될 수 있다는 것은 이해하지만, 사실 저는 이미지가 다운로드되기를 원합니다. 따라서 그것이 임시적인 해결책이 되기를 바랍니다.
1개의 좋아요
다음으로 해결해야 합니다:
Meta에서 시도해 보겠습니다.
<div>
HTML 블록 안의 이미지:
<img src="..." width=100 height=100>
</div>
6개의 좋아요
이 주제는 5일 후 자동으로 닫혔습니다. 더 이상 새 답변을 남길 수 없습니다.