모바일 버전의 Google Chrome이나 모바일 버전의 Firefox(또는 기타 모바일 브라우저)를 사용하여 문제를 재현해 보세요.
캐시를 지우니 해결됐어요! 감사합니다! 수정: 아니, 아닌 것 같네요. ![]()
오래 방치해 드려서 죄송합니다. 다른 업무로 바빴습니다. 이 플러그인을 곧 다시 확인해 보겠습니다.
@DaleKramer @Hifihedgehog 긴급한 문제가 있으시면 알려 주세요. 이번 주에 확인해 보겠습니다.
the pavilion.io에 빠른 메시지를 다시 추가했습니다. 해당 사이트에서 문제를 재현해 볼 수 있나요?
아마도 이 문제가 이 플러그인을 가리키는 것처럼 보였던 이 이슈를 살펴봐 주실 수 있을까요…
최신 버전에서 빠른 메시지가 깨져서, 메시지를 보내면 다음과 같은 프롬프트가 표시됩니다:
죄송합니다. 기존 주제에 개인 메시지를 생성할 수 없습니다.
맞아요, 저도 같은 오류가 발생하고 있습니다: 죄송합니다. 기존 주제에서 개인 메시지를 만들 수 없습니다.
같은 “PM을 생성할 수 없음” 오류가 발생합니다. 이 커밋 때문일까요?
리포트 감사합니다. 최대한 빨리 확인해 보겠습니다.
문제가 바로 이 부분이었습니다. 해결 방법은 이 커밋에서 변경된 부분을 제외하고 valid? 함수를 오버라이드하는 것입니다.
즉, plugin.rb 같은 파일에서 다음과 같이 작성하세요.
require_dependency ‘post_creator’
class ::PostCreator
def valid?
여기에서 재작성하되, 4줄을 빼고 작성하세요.
내일 아무도 하지 않으면 이거 PR 올릴 것 같아. 오전 내내 이거 보고 있었거든.
그렇게 해주시면 정말 감사하겠습니다. 요즘 일이 좀 많아서요
. 감사합니다!
빠른 수정을 가장 원하지만, 이 수정안의 장기적인 사용 가능성도 우려됩니다. 해당 함수의 핵심 구현부 내부 로직이 변경되면 어떻게 될까요?
네, 동의합니다. 이렇게 하는 건 좋은 방법이 아니에요… 특히 valid? 메서드를 사용할 때는 보안 취약성이 발생할 때까지 기다리는 격이죠. 우리는 디스커스가 그 점에서 다음 워드프레스가 되는 걸 원하지 않으니까요… 그런데 좋은 대안은 무엇일까요?
최근에 저도 이런 일로 고생하고 있습니다. 체크 로직이 가득한 긴 메서드에서, 메서드 중간에 있는 특정 체크 하나만 우회하고 싶은 상황이거든요.
:create_pm_on_existing_topic가 유일한 에러인지 단순히 확인할 수 없어요. 해당 값이 설정되면 코드가 즉시 반환되므로, 그 뒤에 다른 체크도 실패했을 수 있거든요.
최소한 이 모듈을 prepend하고, 새로운 valid? 메서드에서 이것이 퀵 메시지(quick message) 상황인지 확인하는 게 좋겠습니다. 해당 상황이라면 수정된 검증 코드를 실행하고, 퀵 메시지와 관련이 없다면 코어 코드를 호출하기 위해 그냥 return super를 사용하세요. 이렇게 하면 코어 함수가 변경될 때 플러그인 기능만 깨지고, 포럼 소프트웨어의 나머지 부분은 영향을 받지 않게 됩니다.
제거된 체크가 무엇인지 알아보기 위해 두 함수를 줄 단위로 비교해야 했습니다.
if new_topic?
...
else
if @topic.present? && @opts[:archetype] == Archetype.private_message
errors.add(:base, I18n.t(:create_pm_on_existing_topic))
return false
end
...
주석 하나 달았으면 좋았을 텐데 말이죠 ![]()
이런 종류의 원키 패치(monkey patch)를 유지보수하기 쉽게 만드는 더 나은 방법이 있는지 아는 분 계신가요?
(정말 한 문장 안에서 "monkey patch"와 "maintainable"을 함께 사용했나요?
)
사실 [FIX: 기존 토픽에서 새 PM을 생성하려는 시도를 방지 #9029]로 인해 Quick messages가 깨진 이유가 아직 명확하지 않습니다. 9029 수정은 PM과 Topic에는 잘 작동하는데, 왜 Quick messages만 깨지는 걸까요? Quick messages가 새 PM을 게시하는 특정 방식이 9029와 충돌을 일으키고 있기 때문일까요?
네, 그렇게 생각해요. 그리고 #9029에서 그 특정 체크가 추가되었거든요.
이 플러그인에 대한 수정 사항을 방금 push했습니다. 어떻게 되는지 알려주세요.
@Oliver_Walker PR을 올려주셔서 감사합니다. 다른 분들이 언급했듯이 큰 메서드를 오버라이드하는 것은 피하는 것이 좋지만, 시도해 주셔서 감사합니다 ![]()
95%의 경우, 큰 서버 사이드 메서드의 일부를 오버라이드를 고려하고 있다면 프레임워크의 로직과 싸우는 셈입니다(몇 가지 예외는 있을 수 있지만). 마치 오래된 복권 쿠키처럼 들릴 수 있지만, 이것이 현실입니다.
이 경우, 먼저 물어야 할 것은 다음과 같습니다: 일반적인 개인 메시지(Private Message)가 기존 일반 개인 메시지 토픽에 어떻게 추가되는가? 결국 문제는 이 플러그인이 첫 번째 게시물(토픽을 생성하는 게시물)이 아닌 모든 게시물에 private_message 아키타입을 할당하려고 시도하고 있었다는 것이었습니다.
@angus 감사합니다. 테스트를 해보셨나요? 그리고 – 호스팅 파트너인 Communiteq (구 DiscourseHosting)에게 플러그인을 다시 로드해달라고 요청하면 될까요?
