css로 해결할 수 있을지도 모르겠네요. 아예 안 나타나는 건가요, 아니면 위로 스크롤하면 볼 수 있나요? 어떤 브라우저/OS를 사용 중이신가요? 상단에 고정(sticky)되도록 설정해 볼 수도 있겠네요. 문제는 일부 브라우저가 최근 “창의적으로” 브라우저 바를 하단으로 이동시켰다는 점입니다.
브라우저는 Motorola 휴대폰의 Android에서 Firefox와 Chrome입니다. Discourse 앱에서도 동일한 문제가 발생합니다.
버튼 바는 항상 존재하며, 텍스트 박스에서 보이는 첫 3줄 중 어디에든 선택이 있으면 팝업 메뉴 바로 아래에 위치합니다.
우회 방법은 첫 텍스트 앞에 CR/LF(캐리지 리턴/라인피드)를 3개 삽입하는 것입니다. 게시하기 전에 이 추가된 줄바꿈을 삭제하면 됩니다.
1개의 좋아요
네, 방금 테스트해 봤어요. 무슨 말씀인지 알겠네요. 진짜 짜증나죠. 하지만 저한테는 하단에 바가 나오는 게 더 나쁜 것 같아요. 게다가 이걸 어떻게 해야 하는지 조사해야 하는데, 그건 무급으로 해야 하거든요. 물론 더 깔끔한 방법이 있을 거라고 생각해요. 다른 프로젝트들도 같은 문제를 겪고 있고, 표준화된 해결책이 있을 거라고 확신합니다. 하지만 말씀드린 것처럼 다른 우선순위가 있어요. 너무 솔직해서 죄송합니다 
수정: 참고로 우클릭(모바일에서는 더블클릭)을 비활성화하는 방법이 있습니다. https://stackoverflow.com/questions/381795/how-to-disable-right-click-context-menu-in-javascript 하지만 그렇게 하면 사용자가 복사할 수 없어요. 정말 골치 아픈 일이죠…
3개의 좋아요
대안은 가능하지만, 단순히 불편할 뿐입니다.
이 번거로움을 해결하기 위한 모바일용 CSS 접근법이 아마 있을 겁니다. 찾아봐야겠네요.
이러한 특수한 경우를 위해 많은 코드를 추가하는 것은 여러분의 시간과 주의를 낭비하는 좋은 방법은 아닐 것입니다. (게다가 오버헤드도 늘어납니다.)
커뮤니티와 프로젝트를 공유해 주셔서 감사합니다. 정말 감사한 일입니다.
3개의 좋아요
네, 보고해 주셔서 정말 감사합니다. 방금 수정했습니다.
6개의 좋아요
팁 하나 드리자면, Rails는 Ruby 클래스 몇 가지에 .present? 메서드를 추가합니다. 이는 빈 문자열과 비교하는 것보다 더 좋습니다. 주로 배열과 문자열에서 작동합니다.
또한 .present?와 반대인 .empty?도 있습니다.
5개의 좋아요
이미지를 편집기를 통해 업로드해야 하므로 이 버튼을 의도적으로 제거했습니다. 그런데 최근 안드로이드 파이어폭스에서 파일 선택 메뉴가 왜인지 팝업으로 뜨지 않는다는 것을 알게 되었습니다. 이 문제를 조사하려면 원격 디버깅을 설치해야 하므로 수정하는 데 시간이 좀 걸릴 것입니다. 그 동안에는 고급 편집기를 사용하여 이미지를 업로드해 주세요.
수정: 실제로는 완벽하게 잘 작동합니다. 제가 이전에 앱의 카메라 접근 권한을 거부했기 때문에 열리지 않았던 것이었습니다. 따라서 데스크톱에서 사용하는 것과 동일한 이미지 업로드 버튼을 그대로 사용하시면 됩니다. 궁금하시다면 제가 테스트용으로 업로드한 스크린샷을 확인해 보세요:
https://cidian.social/t/file-upload-from-mobile/292
1개의 좋아요
툴바에서 볼드, 이탤릭, 링크, 이미지 업로드 옵션만 활성화하려면 어떻게 해야 하나요?
1개의 좋아요
완료되면 설정할 수 있는 옵션을 추가하겠습니다.
4개의 좋아요
이 말은 이 문제에 대한 우회 방법이 없다는 뜻인가요? 플러그인 내부에서 사용된 CKEditor의 설정 파일을 수정할 수 없나요?
이미지 주석, BB 마크업 등 다른 플러그인과의 호환성을 지원할 계획인가요?
3개의 좋아요
자, 한 가지 명확히 할게요. 제가 "동작하지 않는다"고 말할 때는 단순히 WYSIWYG 입력창에 렌더링되지 않는다는 뜻입니다. 최종 게시글에서는 모든 기능이 정상적으로 작동합니다. 이 에디터는 현재로서는 마크다운을 생성하는 또 다른 방식일 뿐이며, 최종 출력물은 여전히 마크다운입니다. 제 관점에서는 “HTML 전용” 방식이 미래를 위한 올바른 방향입니다. 마크다운, BBCode 등은 지나치게 복잡한 사용자 경험을 제공하는 과거의 산물입니다. 하지만 당연히 모든 BBCode 기능이나 커스텀 플러그인을 구현할 수는 없습니다. 그로부터 얻을 수 있는 이점이 없기 때문입니다. 무엇보다 제 자신의 사용 사례를 최우선으로 생각합니다. 하지만 동시에 다른 사용자를 위한 Discourse의 UX를 단순화하는 것도 중요하게 생각합니다. 만약 여러분이 에디터에서 마크다운, BBCode, 그리고 이런 "태그"들을 선호한다면, 이 방향이 여러분에게 적합하지 않을 수 있습니다.
또한 이 토론이 더 건설적으로 진행되기를 바랍니다. 사람들이 현재 에디터 대신 WYSIWYG 에디터를 사용하고자 하는 사용 사례와 이유에 대해 듣고 싶습니다. 이 기능에서 기대하는 이점과 달성하고자 하는 목표가 무엇인지도 궁금합니다.
그러면 어떤 방향으로 나아갈 수 있을지도 모릅니다. “이런저런 무작위 기능들을 다 할 수 있나? …(무료로?)” 같은 질문은 도움이 되지 않습니다.
감사합니다,
Spirobel
6개의 좋아요
HTML로 전환하고 마크다운을 지원하지 않으면, 플러그인이 꺼진 상태에서 HTML로 작성된 모든 게시물을 더 이상 수정할 수 없게 됩니다. 맞습니까?
1개의 좋아요
@spirobel 개인적으로 플러그인을 사용하지는 않지만, 그 기능성을 존경하며 훌륭한 노고에 박수를 보냅니다!
bbcode가 레거시 문법이라는 점에는 동의할 수 있지만, Markdown이 과거의 유산이라는 주장은 제 관점에서 정확하지 않습니다. 오히려 정반대로, 기본 기능 세트는 오랫동안 유지될 것입니다.
주요 이유는 두 가지입니다.
- 타이핑으로 서식 지정 - 단순히 타이핑만으로도 텍스트를 올바르게 서식 지정할 수 있어 집중하고 생산적으로 작성하는 데 용이합니다.
- 렌더링되지 않아도 가독성 확보 - 기본 Markdown 문법은 원본 텍스트 상태에서도 직관적으로 읽을 수 있어 여러모로 매우 편리합니다.
Markdown 기능을 확장(이미지, 테이블 등)하려 할 때, 가독성이 낮은 문법으로 인해 입력이 번거로워지면서 기능이 흔들리거나 때로는 깨지는 경향이 있다고 생각합니다.
제 생각에, 가장 좋은 편집기는 일종의 하이브리드 솔루션을 제공합니다.
- 기본 문법 서식은 편집 모드에서도 문법 기호가 표시된 채로 인라인으로 렌더링됩니다.
- 확장 기능(이미지, 테이블 등)은 편집 모드에서도 당연히 렌더링되어야 하며, 화면에 실제 문법 기호로 표시되지 않는 것이 좋습니다. 감히 말씀드리자면, 이러한 기능들은 플러그인으로 간주되고 데이터 유형에 가장 적합한 형식으로 저장되어야 합니다.
6개의 좋아요
댓글 남겨주셔서 정말 감사합니다!
말씀하신 내용은 잘 이해합니다. 하지만 여전히 동의하기 어렵습니다. 
장기적으로 보면 파워유저들은 단축키를 통해 더 나은 경험을 할 수 있습니다. 예를 들어, 기울임체(it)를 위한 단축키를 만들 수 있습니다. 이렇게 하면 타이핑을 계속하면서 단축키를 누를 수 있습니다. 단축키는 CTRL+*처럼 마크다운을 사용하는 것과 거의 유사한 형태가 될 수도 있습니다.
2번 항목에 대해 말씀드리자면, HTML도 항상 렌더링(브라우저에서)되기 때문에 가독성이 있다고 볼 수 있습니다. 그리고 텍스트 에디터에서 HTML 조각을 봐도 읽을 수 있습니다. 물론 마크다운이 조금 더 깔끔해 보일 수는 있지만, 아주 기본적인 기능에만 머무는 경우이고, 그 경우라면 어차피 큰 차이가 없습니다.
아쉬운 점은 하이브리드 솔루션은 실현 불가능하다는 것입니다. HTML만 사용하는 방식을 선택한 이유 중 하나는, 언어 파서 버그를 디버깅하는 동안 컴퓨터 언어학 박사 학위를 따는 대신 사용자 인터페이스 구축에 집중할 수 있기 때문입니다. 기술 부채를 줄이는 것이 목표이지, 더 쌓아 올리는 것이 아닙니다.
결국, 왜 그렇게 생각하시는지 충분히 이해합니다. 저도 마크다운에 관한 글들을 읽어봤습니다. 하지만 제가 하려는 일에는 HTML 전용 패러다임이 더 설득력 있어 보입니다. 마크다운을 정말로 좋아하는 사람들을 설득하는 것은 의미가 없다는 것도 잘 알고 있습니다. 그들은 현재와 같은 에디터를 계속 사용하면 됩니다. 하지만 다른 방향으로 가고 싶어 하는 또 다른 집단이 있을 수 있다고 생각합니다. 이 플러그인은 WYSIWYG 에디터 그 이상입니다. 마크업 언어를 배울 필요 없이 사람들이 구조화된 데이터를 함께 편집할 수 있도록 소프트웨어를 구축하는 것이 제 비전입니다. 위키백과나 위키낱말사전 같은 대규모 프로젝트와 그 기여 과정에 얽힌 수많은 형식적 요소를 보면, 버려지는 잠재력이 너무 많습니다. 저는 그것을 바꾸고 싶습니다. 그리고 그렇게 하려면, 데이터 입력에 마크업 언어가 필요하다는 개념을 버리고 디스코스의 협업 기능을 활용해야 합니다.
디스코스에서 마크업 언어가 처음 사용된 이유와 그 배경은 매우 타당하다고 생각합니다. 하지만 제 목표는 다르기 때문에, 저도 다른 패러다임을 따릅니다.
5개의 좋아요
훌륭한 플러그인입니다, @spirobel! 이건 기술에 익숙하지 않은 우리 사용자들이 꼭 필요한 기능인 것 같고, 사이트 운영에 상당한 도움이 될 거라고 생각합니다. 개발에 쏟아부으신 시간과 노고에 감사드립니다. 몇 가지 문제를 발견했는데, 참고가 될 것 같습니다.
Shared Edits와의 충돌
방금 이 플러그인과 Discourse Shared Edits 를 모두 설치했는데, 예상대로 약간 충돌이 발생합니다. 하지만 해결 가능한 방식으로 보이기도 합니다. 호환성을 맞춰보실 의향이 있으신가요? 개인적으로는 이 두 기능이 앞으로 모두 필수적이라고 생각합니다.
기본 편집기(Basic Editor)로 게시물을 Shared Edit(공유 편집)하면, 게시물에 있던 기존 텍스트가 지워지고 편집을 되돌리기 전에는 복원할 수 없습니다.
@멘션 제안이 표시되지 않음
Discourse 기본 편집기가 @멘션 기능을 부분적으로 깨뜨리는 것 같습니다. 여기서 여러분을 멘션하려고 하면 다음과 같은 화면이 나타납니다:
기본 편집기를 활성화하면 더 이상 제안이 표시되지 않습니다. 고급 편집(Advanced Editing)을 클릭해도 같은 문제가 발생합니다.
6개의 좋아요
네. 아직 진행 중인 작업입니다. 멘션(언급) 기능은 제 작업 목록에 있습니다. 공유 편집은 아직 확인하지 않았지만, 구현하는 것은 충분히 가능합니다. 다만, 공유 편집 플러그인과의 호환성을 보장하는 방식으로 진행되지는 않을 수 있습니다. 기본 편집기가 도입하는 변경 사항이 꽤 크므로, 결국 기본 편집기 내부에서 해결해야 할 가능성이 높습니다.
4개의 좋아요
@sam과 이에 대해 이야기해 보셨나요? 그는 이 가능성에 관심이 있을 수 있으며, 분명 현명한 조언을 해 줄 것입니다.
1개의 좋아요