제가 이해한 바로는, 코어에 이미 번들링되어 있는 플러그인이 app.yaml에 나열되어 있다면, 해당 항목은 단순히 무시된다는 것입니다. 이 경우 app.yaml에 포함하는 것이 중복된다고 알리고, 소유자가 이를 제거할 수 있다는 통지가 표시된다는 뜻입니다.
저도 app.yaml에 플러그인이 하나라도 나열되어 있는 한, 업데이트 실패의 위험이 항상 있다는 점이 조금 번거롭게 느껴집니다. 그래서 업데이트를 할 때마다 내 플러그인 중 하나가 코어에 추가되었는지 반드시 두 번 확인해야 합니다.
Sysop을 위해 이를 대신 수행하는 스크립트를 만들어 두면 안 될까요?
저는 개인적으로 플러그인을 팀이나 작성자별로 정리하여, 어떤 플러그인이 공식적인 것인지 등을 파악하기 쉽게 합니다. 하지만 Discourse를 더 사용자 친화적으로 만들겠다는 목표라면, 이는 개발 팀 차원에서 이루어져야 할 일입니다.
사용자가 Postreq(이것이 맞나요?) 업그레이드 실패로 인해 업그레이드가 깨진 경우 도움을 주셨을 때와 크게 다르지 않다고 봅니다.
플러그인의 경우, Procourse Installer 개념은 커맨드라인을 사용할 필요 없이 플러그인 설치와 삭제를 단순화한다는 점에서 훌륭한 아이디어였습니다.
물론 문제가 발생했을 때 더 다듬어졌어야 했을 수도 있습니다. 하지만 로그 파일이나 필요 시 커맨드라인으로의 간단한 폴백을 통해 충분히 해결할 수 있었을 것입니다. 이 기능이 셀프 호스팅을 유료 플랜보다 더 매력적으로 만들 수 있다는 점은 인정합니다. 그럼에도 불구하고, 유료 플랜을 선택할 만큼 충분한 장점이 여전히 존재합니다.
이러한 유형의 플러그인 관리자는 호스팅 플랜이 해당 호스팅 등급 내에서 플러그인을 설치할 수 있도록 제작되거나 포크될 수도 있습니다. 특정 플랜에서는 일부 플러그인이 필요하지 않을 수 있기 때문입니다.
실제로 저는 이전에 채팅이 번들링되어 있다는 오래된 게시글을 놓치고 설치하려고 시도한 적이 있었습니다. 플러그인의 태그가 업데이트되지 않았다고 생각합니다. 물론 사이트가 크래시쳤는데, 이론상으로는 불필요한 항목이므로 무시하고 재구축이 완료되었음을 알리며 제거할 수 있었다면 되었을 텐데, 플러그인 설치를 시도하는 것을 좋아하지 않아서 그랬던 것 같습니다.
좋아요, 피드백을 받았습니다! 
이제 이 주제를 닫을 수 있을 것 같습니다. 원하시는 동료분들이 답변할 수 있도록 타이머를 설정해 두겠습니다.
whos-online 플러그인이 코어에 포함될까요?
최근 공식 플러그인을 코어에 더 많이 번들링하려는 이니셔티브가 진행 중이라, Who’s Online 플러그인이 포함 대상에 고려되고 있는지 궁금합니다.
이 플러그인이 공식 호스팅 플랜에서 사용 가능한 것(플러그인 할당량에 포함됨)을 확인했는데, 이것이 더 넓은 채택으로 향하는 움직임임을 시사하는지 궁금합니다.
성능 제약이나 철학적 적합성 문제로 인해 기본적으로 비활성화되어 있어야 하며, app.yml에서 명시적으로 다르게 설정하지 않는 한 그 상태를 유지해야 한다는 점은 충분히 이해합니다.
감사합니다!
현재 더 이상의 플러그인을 코어로 이동할 계획은 없습니다. Cakeday가 마지막이었으며, 이전에 기본적으로 활성화되어 있던 방식에 따른 몇 가지 복잡한 문제로 인해 메인 배치와 별도로 처리해야 했습니다.
여기서 프로세스에 대한 좌절감을 충분히 이해합니다. 분명히 제가 원하는 만큼 매끄럽지는 않거든요. 맥락을 설명해 드리자면: 근본적인 문제는 app.yml 파일이 Discourse 설정 파일이 아니라는 점입니다. 이들은 pups 설정이며, 플러그인 설치 줄은 단순히 셸 명령어입니다.
pups에 Discourse 특유의 로직을 가져와 특정 셸 명령어를 무시하도록 하는 것은 실제로 옵션이 아닙니다. 이 도구는 Discourse에만 사용되지 않으므로요. 또한 부트스트랩 중에 실행되는 셸 명령어가 자신의 지식을 모르고 변경되는 것을 불쾌하게 여길 사람들이 상당수 있을 것으로 예상됩니다.
따라서 사용 가능한 도구로 찾을 수 있었던 가장 깔끔한 해결책에 도달했습니다: CLI 재빌드를 강제하고, 영향을 받는 줄을 설정에서 제거해 달라는 메시지를 표시하는 것입니다.
흥미로운 글이네요, 데이비드!
Who’s Online 플러그인 토픽의 원문에서 무언가를 발견했습니다:
이 플러그인을 설치하기 전에 신중하게 고려하세요
기술적으로 맞다면, 거기의 **“설치(installing)”**라는 표현을 **“활성화(enabling)”**로 바꾸는 것이 더 나을 것 같습니다.
현재의 표현은 추가 번들 플러그인이 존재하는 것이 철학적 또는 성능상의 문제인 것처럼 오해받을 수 있습니다. 실제로는 단순히 해당 플러그인이 활성화되어 있느냐의 문제입니다. 이전에 활성화되지 않았던 신규 코어 플러그인은 재빌드 후 기본적으로 비활성화 상태이므로, 위험은 코어와 함께 설치되어 있다는 데 있는 것이 아니라, 그것을 켠다는 데 있습니다.
반드시 그런 것은 아닙니다. 설치되어 있지만 비활성화된 플러그인도 실제로 성능 문제를 일으킬 수 있습니다. 예를 들어 Disabled plugins still causing performance impact 를 참조하세요.
해당 특정 문제는 번들 플러그인의 경우 대부분 해결되었지만, 다른 플러그인에서는 여전히 간헐적으로 이러한 현상이 발생할 수 있습니다.
discourse-categories-suppressed 플러그인은 최신 피드에서 선택된 카테고리를 숨기는 간단하고 선택적인 UI를 추가합니다. 이 플러그인은 다음 위치에 있는 단일 드롭다운 메뉴를 통해 통합됩니다:
관리자 → 설정 → 카테고리
“categories suppressed from latest”
이것은 매우 자연스러운 핵심 설정처럼 느껴집니다. 특히 다음과 같은 이유에서입니다:
• 공식적으로 유지 관리되고 있습니다
• 관리자가 활성화하지 않는 한 기본적으로 비활성화 상태로 유지됩니다
• 많은 커뮤니티(저희 커뮤니티 포함)가 ‘최신’을 주요 랜딩 뷰로 사용하며, 여기에 표시되는 콘텐츠에 대한 더 세밀한 제어 기능을 원합니다
이 플러그인을 번들링(기본적으로 비활성화 상태로)하는 것을 팀에서 고려해 주실 수 있을까요? 그러면 관리자가 추가 설치 없이 이 토글을 사용할 수 있을 것입니다.
고려해 주셔서 감사합니다. 이는 많은 사이트가开箱(out-of-the-box)으로 활용할 수 있는 작은 UI 환경 설정처럼 보입니다.
이 주제는 2일 후 자동으로 닫혔습니다. 더 이상 답변이 허용되지 않습니다.
이것이 의도된 것인지 확실하지 않지만, 보고하고자 합니다:
저희는 구형 안정판 v3.5.4를 사용 중이며 cakeday 플러그인을 사용하고 있었습니다. 그러나 cakeday가 코어에 병합되었기 때문에 (같은 Discourse 버전의) 재빌드가 작동하지 않았습니다. 그래서 yml 파일에서 플러그인을 비활성화했는데… 글쎄요, 사라졌습니다. 이제 다시 빌드가 되지만, 관리자 UI에 해당 기능이 설치되어 있다는 표시가 전혀 없어 케이크 데이(Cake Day) 기능이 없습니다.
구형 안정판을 사용하고 있기 때문일 것 같지만, 같은 버전의 Discourse를 재빌드했을 때 예상치 못한 결과였습니다.
cakeday 플러그인은 3.5.4에 번들링되어 있지 않으므로, 더 이상 보이지 않는 이유는 그것일 것입니다.
재빌드가 실패하기 시작한 이유가 정말 그것이라고 확신하십니까? 만약 다음과 같은 내용을 보셨다면:
HINT: The plugin ‘$plugin’ is now bundled with Discourse and should not be included in your container configuration
그렇다면 cakeday 플러그인이 구성 파일에 포함된 경우 실패한 재빌드에서 모두 이 메시지가 표시될 것입니다. 이는 이 문제에 대해 사용자에게 경고할 수 있는 가장 효율적인 방법이었지만, 구버전 코어를 실행 중인 사용자에게는 혼란을 줄 수 있습니다.
따라서 cakeday 플러그인이 필요하시다면 app.yml 파일에 다시 추가하고 재빌드할 수 있을 것입니다. 실패는 다른 원인으로 인해 발생했으며, 이제 해결된 것으로 보입니다.
참고로: 지원되는 버전으로 업그레이드하는 것을 강력히 권장합니다. 3.5는 더 이상 보안 업데이트를 제공하지 않으며, 공격에 취약할 수 있습니다.
Cloning into 'docker_manager'...
I, [2026-03-09T15:05:49.126710 #1] INFO -- : > cd /var/www/discourse/plugins && git clone https://github.com/discourse/discourse-cakeday.git
fatal: destination path 'discourse-cakeday' already exists and is not an empty directory.
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse/plugins && git clone https://github.com/discourse/discourse-cakeday.git failed with return #<Process::Status: pid 146 exit 128>
Location of failure: /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.4.0/lib/pups/exec_command.rb:138:in `spawn'
exec failed with the params {"cd"=>"$home/plugins", "cmd"=>["git clone https://github.com/discourse/docker_manager.git", "git clone https://github.com/discourse/discourse-cakeday.git", "git clone https://github.com/discourse/discourse-whos-online.git", "git clone -b no-regional-flags https://github.com/mentalstring/discourse-nationalflags.git", "git clone https://github.com/discourse/discourse-yearly-review.git", "git clone https://0fa273b19b56a1a58c41484d49a01d99f1b5b8d2@github.com/mentalstring/custom-username-validator", "git clone https://github.com/discourse/discourse-saved-searches"]}
bootstrap failed with exit code 128
---
HINT: The plugin 'discourse-cakeday' is now bundled with Discourse and should not be included in your container configuration.
Remove the line 'git clone https://github.com/discourse/discourse-cakeday' from your containers/web_only.yml file, then try again.
For more information, see https://meta.discourse.org/t/373574
---
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
app.yml에 플러그인을 다시 추가하면 위의 오류가 발생합니다. 제거하면 즉시 빌드가 다시 작동합니다. 이 플러그인이 유일한 문제인 것 같습니다.
현재 구버전을 사용 중이며 업그레이드가 로드맵에 올라가 있다는 점은 알고 있습니다. 다만, 실행 중인 버전은 변경하지 않았음에도 3.5.4 버전에서 플러그인 포함 시 빌드가 정상적으로 되던 것이 플러그인 포함 시 더 이상 빌드되지 않는 상황이 되었고, 플러그인 기능(플러그인 또는 코어 통해)을 되찾을 방법이 없는 것 같다는 점을 지적하고 싶었습니다.
흥미롭네요! 이제 docker 이미지에 discourse-cakeday가 포함되었기 때문일까요? 그리고 코어가 3.5로 "하위 호환성 업데이트(downgrade)"되면 빈 디렉터리가 남게 되는 것 같습니다.
git clone https://.../discourse-cakeday 줄 앞에 rm -rf discourse-cakeday를 추가하면 정리될 것입니다. 그러면 다음과 같이 보일 것입니다:
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
- rm -rf discourse-cakeday
- git clone https://github.com/discourse/discourse-cakeday
네, 그게 맞았어요. 다시 작동합니다 — 감사합니다!
이 주제를 약간 벗어난 이야기로 가져온 점 죄송합니다. 더 적절한 토픽이 없는 것 같고, 이전 문제와 다소 관련이 있어 이렇게 올리게 되었습니다.
지난번 메시지 이후, discourse/docker_manager에서 추가적인 변경 사항이 이루어져 이전 버전 빌드에서 더 많은 문제가 발생하고 있다고 생각합니다. 오늘 재빌드한 후, Discourse의 관리자 섹션 전체가 다음과 같은 오류와 함께 작동하지 않게 되었습니다:
loader.js:247 Uncaught (in promise) Error: Could not find module `discourse/admin/models/admin-plugin` imported from `discourse/plugins/docker_manager/discourse/models/repo`
yml 파일에 다음 내용을 사용하여 빌드를 수정할 수 있었습니다:
- git clone https://github.com/discourse/docker_manager.git && cd docker_manager && git reset --hard 314bbd78c200860c76bb62ced65b40e7cde5aa02 && cd ..
어떤 커밋이 문제를 일으켰는지 정확히 알 수는 없지만, 이렇게 하면 다시 작동하는 것을 확인했습니다.
알고 있습니다, 알고 있습니다. 업그레이드해야 합니다(진심으로요). 하지만 저희와 같이 여러 가지 이유로 계획보다 오래 이전 버전을 유지해야 하는 다른 사용자들도 있을 것입니다. 버전 변경 없이 이전 빌드가 깨지는 것은 다소 예상치 못한 일입니다.
어쨌든, 업그레이드할 때까지 우회 방법을 찾았으니, 같은 상황에 있는 다른 분들에게 도움이 될 수 있을지 모르아 공유합니다.
현재 사용 중인 Discourse 코어 버전은 무엇입니까? 여전히 3.5인가요?
네, 3.5.4입니다. 곧 업그레이드할 예정입니다.