@gdpelican 님이 지난 1주일간 응답이 없어 수정 사항을 생성하고 PR을 제출했습니다. 수정 사항이 메인 저장소에 통합될 때까지 대체 저장소를 사용하실 수 있습니다.
대체 저장소: https://github.com/PuttyTribe/babble
PR: Fix issue with search controller - Pull Request #302 - gdpelican/babble - GitHub
전환하려면 설정을 변경하여 기존 babble 저장소를 https://github.com/PuttyTribe/babble.git 으로 교체한 후 다시 빌드하시면 됩니다.
오, 타이밍이 딱 맞았네! 
일주일 동안 활동이 없다가 20분 간격으로 두 가지 해결책이 올라오다니!
처음에는 그 해결책을 선택했는데, 결국 해당 매개변수가 어떤 경우에도 사용되지 않으므로 포괄적인(catch-all) 방식으로 처리하기로 했어.
@merefield 님의 이 문제를 수정하는 PR을 병합했습니다.
@ti0 님도 PR을 올려주셔서 감사합니다. 해당 인자는 실제로 사용되고 있습니다 인자 없이 super를 호출하면 (즉, super() 대신) 하위 클래스의 인자가 자동으로 super에 전달됩니다. 오버라이드되는 메서드를 살펴보면 인자가 어디에서 사용되는지 확인할 수 있습니다: discourse/lib/search.rb at main · discourse/discourse · GitHub.
@ti0 @merefield 참고로, 플러그인에서 Search 클래스에 새로운 type_filters를 추가하기 위한 훅을 Discourse 코어에 추가하는 PR을 만드는 것이 좋겠습니다. execute 메서드를 패치하는 것보다 성능과 안정성이 더 좋을 것입니다. Discourse 팀이 이것이 추가 기능으로서 가치가 있다고 설득할 수 있다면 흥미로운 작은 프로젝트가 될 수 있을 것입니다.
@justin 님, 결국 해결하셨나요? 제 개인 브랜치에서 babble이 엔진을 로드하는 방식을 변경하기 전까지는 동일한 문제를 겪었습니다. @gdpelican 님의 이니셜라이저에서 파일을 로드하는 방식과 다른 환경들이 어떻게 처리하는지와 관련된 문제인 것 같습니다. 즉,
require Rails.root.join('plugins', 'babble', 'app', path).to_s
정확한 원인을 파악하기는 어렵습니다. Babble의 파일 로드 방식을 업데이트하는 PR을 만들어보고, require와 Rails.root 대신 load와 File.expand_path를 사용하는 표준 Discourse 플러그인 방식으로 변경하는 것에 @gdpelican 님이 동의하는지 확인해볼 계획입니다.
수정 Babble을 try.thepavilion.io에도 추가했습니다. 24시간마다 업데이트되는 환경에서 테스트해볼 수 있습니다.
앞으로 Babble에 치명적인 버그가 발생하여(즉, 완전히 작동하지 않을 경우) James 님이 없을 경우, @angus 또는 @merefield 님에게 멘션을 달아주시면 수정하거나(PR 리뷰 포함 ) 대응하겠습니다.
제 의도는 우리가 수정한 오버라이드된 메서드 내에서 해당 매개변수가 사용되지 않는다는 것이었습니다. 말씀하신 내용대로라면, super 호출이 이름 있는 인수를 수집하는 **args를 그대로 전달하기 때문에 제 코드는 여전히 동작해야 합니다. 또한, 향후 다른 매개변수가 추가되더라도 더 안정적입니다. 맞습니까? 아니면 제가 놓친 부분이 있습니까?
네, 맞습니다
조금 테스트를 해봤는데, 질문자님의 방식도 당장의 목적(즉, readonly_mode 기능 유지)에는 잘 작동하는 것 같습니다. 다만 개념적으로 조금 이상하게 느껴질 수 있는데, **args는 이론적으로 슈퍼클래스가 호출되기 전에 설정되어야 하니까요. 개인적으로(제임스는 다른 의견을 가질 수도 있겠지만) 저는 더 명시적인 방식을 선호합니다. super를 호출하는 것만으로 이미 인자가 암묵적으로 전달되고 있는데, **args를 통해 암묵성을 더하는 것은 너무 복잡해지는 것 같아서요.
질문자님이 말씀하시는 의도는 이해하지만, 전체적으로 볼 때 이런 상황에서 더 나은 방법은 코어 코드와의 충돌을 암묵적인 캐치올(catch-all) 메서드를 통해 피하는 것이 아니라, 명시적인 방식으로 해결책을 찾는 것이라고 생각합니다. 후자의 접근 방식은 나중에 다른 문제를 일으키는 경우가 많습니다. 위에서 언급했듯이, 코어 코드베이스에 새로운 type_filter를 추가하는 방향으로 리팩토링할 수 있다면 좋겠습니다. 꽤 좋은 소규모 프로젝트가 될 것 같네요.
모든 사용자에게 기본적으로 "페이지 로드 시 채팅 자동 열기"를 "예"로 설정하는 것이 가능한가요?
Babble에서 Threads처럼 URL을 렌더링할 수 있을까요?
예를 들어, Babble Chat에 Twitter 링크를 게시하면 URL만 표시되는 대신 트윗 내용이 표시되는 것과 같은 방식입니다.
Memberful과 연동한 후 채팅에서 계정 이름 아래에 사용자의 실명이 표시되는 경험을 하신 분이 계신가요?
가능하다면 실명이 표시되지 않도록 숨기고 싶습니다.
수정: 임시 해결책을 찾았습니다. 가입 시 멤버들이 실명 대신 닉네임을 전체 이름으로 입력하도록 하거나, 온보딩 후 전체 이름을 닉네임과 동일하게 수동으로 수정하는 방식입니다.
2020년 9월 17일 기준으로 이 기능을 사용하고 계신 분이 계신가요?
부수적인 프로젝트(side project)가 아닌지 확인하고 싶었습니다.
@angus 님, 현재 가장 활발하게 활동 중인 Babble 헬퍼가 당신일 것 같습니다. 그래서 코드 업데이트 요청을 당신에게 보내지만, 다른 분도 이 문제를 해결해 주시면 감사하겠습니다.
저는 방금 Discourse 버전을 2.6.0beta2(구체적으로 이 GitHub 커밋 버전)으로 업데이트했는데, 이제 이모지 피커가 작동하지 않습니다.
@itsbhanusharma 님은 우리의 Discourse 설치 문제를 도와주고 있으며, 그의 초기 추측은 Discourse 코어에서 이모지 피커 업데이트와의 호환성 문제일 가능성이 있다는 것입니다.
환경:
브라우저: Firefox 또는 Chrome (최신 빌드)
뷰: 데스크톱, 태블릿, 모바일
재현 가능성: 100%
재현 방법:
기대되는 결과:
이모지 피커 UI가 열립니다.
실제 결과:
아무 일도 일어나지 않습니다. 이모지 피커 창이 열리지 않습니다.
복잡해지지 않는다면, 이모지 피커 문제를 수정하는 분은 누락된 번역도 함께 수정해 주시면 좋겠습니다.
채팅 메시지 옆의 “…” 아이콘을 클릭하면, 플래그 옵션이 “Flag” 대신 "[en_US.post.actions.flag]"로 표시됩니다.
Babble의 이모지 선택기가 내 사이트에서도 더 이상 작동하지 않습니다.
게시판이 무작위로 위로 스크롤되는 문제도 있습니다. 이전에 한 번도 이런 문제가 있었던 것 같습니다.
@angus 또는 요즘 Babble 관련 기술적 도움을 줄 수 있는 다른 분 — 3주 전 이 포럼 답변에서 보고한 두 가지 문제를 해결할 희망이 있을까요?
빠른 답변 감사합니다, Joel.
새로운 Discourse 이모지 선택기에 대한 지원을 추가했습니다.
이 부분도 함께 해결했습니다.
안녕하세요 @angus, 이 플러그인에 대한 수고 많으셨습니다!
저의 discourse 시스템은 커스텀 long polling base url로 동작합니다. 방금 Babble을 추가했는데, Access-Control 헤더(CORS)를 전혀 추가하지 않아 여러 요청이 실패하는 것을 확인했습니다.
코드에 대한 올바른 방향을 알려주시면 제가 수정을 작성해 볼 수도 있습니다.
최신 discourse 업데이트와 최신 버전의 babble을 설치한 후(며칠 전과, 수정되었는지 확인하기 위해 어제 다시 설치했는데), 메시지 전송에 문제가 발생하고 있으며, 읽음 표시도 새 메시지가 있다고 표시된 상태로 고정되어 있습니다.
방금 메시지를 전송하지 못했을 때 브라우저 콘솔에 다음과 같은 오류가 여러 개 발생했습니다:
Uncaught Error: No Reason Phrase
jQuery 13
error _application-49dab3118e527975ea48703627a0152cbe26663b7fde8423c667b094d716ae08.js:8967
jQuery 4
_ember_jquery-865569b174cc91f4563f3552f437b32c6eadf9f6c3d49eae02cfe50e5a8c7dfa.js:38573:14
jQuery 13
u self-hosted:1177
error _application-49dab3118e527975ea48703627a0152cbe26663b7fde8423c667b094d716ae08.js:8967
jQuery 4
포럼 계정 목록에서 "f5c…"로 시작하는 이상한 사용자 이름(예: f5cfe2e6cc098d)을 가진 계정들이 발견되었습니다 - This is the problem of a specific user or something else?
이 플러그인에서 이전에 이러한 문제를 본 적이 있나요?
