오류 메시지에 reactions, data explorer, solved 항목이 여전히 yml 파일에 있다고 표시된다면, 실제로 해당 항목들이 파일에 남아 있을 가능성이 높습니다. 해당 항목들을 주석 처리했다고 생각하신다면, 두 번 입력된 것은 아닌지 확인해 보시기 바랍니다.
반드시 설정을 검토하여, 해당 yml 파일이 자신의 사이트와 일치하는지 확인하는 것이 좋습니다.
1개의 좋아요
안녕하세요
최신 3.4.6 stable 버전으로 포럼을 성공적으로 업그레이드했습니다. 그전까지는 인증을 위해 독립형 discourse-oauth2-basic 플러그인을 사용하고 있었습니다.
/admin/plugins에 Oauth2 Basic 로그인 옵션이 없습니다.
제 discourse 버전은 3.4.6입니다.
힌트: 플러그인 ‘discourse-oauth2-basic’은 이제 Discourse에 번들로 포함되어 있으므로 컨테이너 구성에 포함해서는 안 됩니다.
containers/app.yml 파일에서 ‘git clone GitHub - discourse/discourse-oauth2-basic: A basic OAuth2 plugin for use with Discourse’ 줄을 삭제한 후 다시 시도해 주세요.
자세한 내용은 Bundling more popular plugins with Discourse core를 참조하세요.
3.4.6으로 업그레이드하기 전에 discourse-oauth2-basic 플러그인을 제거해야 했습니다.
무엇이 잘못되었을지 이해하는 데 도움을 주실 수 있을까요?
- 프로세스를 오해한 건지, 플러그인이 여전히 필요한 건가요?
- 플러그인을 제거한 후 핵심 OAuth2 기능을 활성화하기 위해 놓친 추가 단계가 있나요?
- 아니면 설정을 잘못된 곳에서 찾고 있는 건가요?
감사합니다!
1개의 좋아요
음… 스테이블 버전이라 그런 건가요?
시스템 프롬프트에 따라 discourse-oauth2-basic 플러그인을 제거한 후 3.4.6 안정 버전으로 성공적으로 업그레이드했습니다.
하지만 이제 관리자 대시보드에서 OAuth 2 Basic 설정 옵션이 사라진 것을 발견했습니다.
1개의 좋아요
안정판(stable)을 사용하고 계시다면, 다음 안정판이 8월 초에 출시될 때까지 이 주제는 적용되지 않습니다. 따라서 app.yml에 oauth2-basic을 다시 추가해야 합니다. 원래 실패는 다른 이유로 인해 발생했을 것입니다.
불행히도 ‘힌트’ 로직은 매우 지능적이지 않으며, 안정판과 tests-passed를 구별하지 못합니다.
5개의 좋아요
저도 같은 생각입니다. 그런데 이걸 어떻게 해야 할까요? ㅋㅋ 제 생각에는 네이티브 리소스, 즉 플러그인을 더 많이 제공하는 것, 심지어 비활성화된 상태의 플러그인도 포함하는 것은 초보자가 직접 호스팅을 하도록 돕는 좋은 해결책이 아닙니다.
2개의 좋아요
@nat 이거 봐, 내 인용 번역과 내 답변이야
3개의 좋아요
플러그인 섹션의 클론 관련 행을 주석 처리하려고 여러 번 시도해 보았지만, 플러그인을 설치하려고 할 때 해당 행이 여전히 읽혔습니다. 어떻게 해야 했을까요? 해당 행을 삭제했고, 마침내 작동했습니다.
업그레이드를 수행할 때는 Discourse 코어에 포함된 플러그인 목록을 확인해야 합니다. app.yml 파일에 해당 행이 있는 경우, 플러그인 섹션에 추가하지 않도록 하거나 해당 행을 제거해야 합니다.
2개의 좋아요
이들이 사전 설치되어 있으므로, 설치된 목록에서 이들을 분리할 수 있는 옵션이 있어야 합니다. 설치된 목록은 제거할 수 있지만, 사전 설치된 항목은 비활성화만 가능한 상황이니까요.
아마도 코어에 통합된 플러그인은 '추천 플러그인’이나 ‘코어 플러그인’ 같은 별도 카테고리로 분류하는 것이 좋겠습니다.
물론 ‘전체’ 필터도 함께 제공하면 좋겠습니다.
2개의 좋아요
그들의 제안은 이상적이지는 않지만, 작동은 합니다. 예시:
## Plugins go here
## see https://meta.discourse.org/t/19157 for details
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
- git clone https://github.com/discourse/docker_manager.git
- git clone https://github.com/pfaffman/discourse-allow-pm-to-staff.git
#- git clone https://github.com/discourse/discourse-hcaptcha.git
#- git clone https://github.com/discourse/discourse-calendar.git
- rm -rf discourse-adplugin
- rm -rf discourse-affiliate
- rm -rf discourse-ai
- rm -rf discourse-apple-auth
- rm -rf discourse-assign
- rm -rf discourse-login-with-amazon
- rm -rf discourse-lti
- rm -rf discourse-microsoft-auth
- rm -rf discourse-patreon
- rm -rf discourse-subscriptions
- rm -rf discourse-zendesk-plugin
(원하시는 대로 조정하세요)
6개의 좋아요
7개의 게시글이 새 주제 Troubleshooting bootstrap failures in Discourse로 분리되었습니다.
여기서 현실은 stable 브랜치가 실제로 LTS이며, 꽤 좋은 LTS라는 점입니다. 보안 업데이트를 제공하며, 어떤 플러그인 버전이 이 브랜치와 호환되는지 매우 명확합니다(.discourse-compatibility 파일 덕분에). 이 모든 것이 제대로 작동하기까지 오랜 시간이 걸렸다는 점은 완전히 인정합니다. 하지만 지난 2년 정도 동안에는 잘 작동해 왔는데, 이는 팀의 훌륭한 성과입니다.
이제 발언의 두 번째 부분입니다. stable이 원하지 않는 것으로 종종 표현되는 것은 사실입니다. 하지만 Communiteq 호스팅에서는 지난 2년 6개월 동안 클라이언트에게 stable(“안정성 우선, 연간 2회 새로운 업데이트, 월 1회 보안 업데이트”)와 tests-passed(“항상 최전선, 월 1회 새로운 기능”) 사이에서 자유롭게 선택할 수 있게 해 왔으며, 85%가 stable을 선택합니다.
그 점은 이해합니다. 하지만 그것은 개발 문제이지 프로덕션 문제가 아닌 것 아닌가요? 개발 환경에서 그렇게 하는 것은 완전히 이해할 수 있습니다. 하지만 기본 프로덕션 설치에 해당 플러그인들을 추가하는 것은 플러그인이라는 개념(정의상 기본이 아닌 것)의 취지를 무색하게 만듭니다.
제가 보는 유일한 실질적인 프로덕션상의 이점은 플러그인 제거와 멀티사이트 호스트와 관련된 매우, 매우 특수한 사례입니다. (다시 말하지만, 이것은 좋은 일이며, 다른 모든 프로덕션 문제는 시간이 지남에 따라 해결되었습니다!)
그것은 사용자가 확인할 수 있는 플러그인 목록을 표시하고 app.yml에 추가하도록 하는 설정 스크립트로도 해결할 수 있었습니다.
하지만 여전히 다른 티어에 대해 다른 (부분) 플러그인 세트를 제공하고 있죠?
6개의 좋아요
저도 app.yml 파일을 주석 해제하는 방식을 더 선호했을 것 같습니다.
1개의 좋아요
이 모든 플러그인은 우리의 모든 셀프서비스 플랜에 설치되어 있습니다. 일부 티어는 액세스 권한이 없지만, 권한이 없더라도 여전히 설치된 상태입니다.
우리는 이 결정을 변경하지 않을 것이므로, 이는 사람들이 그저 받아들여야 할 사항입니다. 일부 사람들이 불만을 표하거나 이에 반대하는 것을 이해하지만, 이는 절대 바뀌지 않을 것입니다.
이것은 개발 중의 속도를 높여 주며, 우리의 선호도를 정의하고, 압도적인 다수의 사용자가 사용하는 Discourse의 안정성을 보장합니다.
다른 플러그인들도 있습니다… 코어 플러그인이 유일한 플러그인은 아닙니다.
5개의 좋아요
게시글이 새 주제로 분리되었습니다: Discourse does not ship an LTS release
인기 플러그인 및 그 기능을 핵심 이미지로 이동시키는 것이 합리적이라는 데 전적으로 동의합니다. 특히 플러그인이 핵심 자체와 동일한 개발자(CDCK)에 의해 만들어졌다면 더욱 그렇습니다. 이는 다른 소프트웨어 프로젝트에서도 일반적인 관행입니다. 다만 부트스트래핑 문제를 해결해야 합니다. 여전히 낙관적입니다 
1개의 좋아요
그것이 재건할 수 없는 이유입니다.
이것이 분명히 더 나은 방법입니다. 이전 게시물에서 언급한 플러그인 제거 코드를 사용하여 구현할 수도 있습니다.
설치 스크립트에 이 기능을 추가하면 기본 제공 옵션이 훨씬 좋아지며, 이는 특정 선택적 기능을 설치할지 여부를 사용자에게 선택하게 하는 일반적인 프로그램 동작과 일치합니다.
호환성 파일은 좋습니다. 하지만 제 생각에는 호환성 정보가 토픽에도 추가되어야 합니다. TC/플러그인이 Stable과 Tests-passed 모두에서 사용 가능한 경우를 위한 링크나 설치 지침을 포함하여 말이죠.
1개의 좋아요
가이드를 공유해 주셔서 감사합니다. ‘automation’ 플러그인을 제외하면 모두 잘 작동합니다. 채팅 플러그인이 이 플러그인에 의존하는 것 같아서 삭제할 수 없기 때문입니다.
1개의 좋아요
솔직히 자동화 플러그인은 정말로 제거되면 안 되는 것 같아요. 유용하게 쓸 수 있는 잠재적 용도가 정말 많거든요. 더 많은 자동화 옵션을 제공하려면 개인적으로 더 많은 시간과 노력이 투자되어야 한다고 생각합니다.
하지만 @RGJ 님이 지적했듯이, 최근 'truly extras’가 어느 정도 통합되면서 설치할지 여부를 묻는 옵션이 생겼다는 점은 좋습니다. 이렇게 하면 불필요한 애드온을 제거해 깔끔하게 정리할 수 있거든요. 셀프 호스팅 환경을 사용하는 사람들을 위해 설치 후 실행되는 별도 스크립트를 제공하는 것도 방법일 수 있습니다. 이렇게 하면 app.yml 파일을 직접 편집해야 하는 부담을 느끼는 사용자들을 배려할 수 있을 거예요.