해당 안내 메시지를 받지 못했습니다. 하지만 오류 로그를 확인하여 해당 줄들을 제거했습니다. 이제 다시 재빌드하고 있습니다.
수정: 업그레이드 전에 이 플러그인 줄들을 제거하지 않으면 오류가 발생하고 20분간 오프라인 상태가 되는 문제를 야기한다면, 왜 기본적으로 설치된 플러그인이라는 불필요한 부피(BLOAT)를 추가해야 하는지 궁금합니다.
더 큰 그림에 대해 궁금합니다. 이러한 플러그인들을 기본적으로 번들링하는 이유는 무엇인가요?
개인적으로는 윈도우, 모바일 OS 및 일부 소프트웨어가 기본적으로 더 많은 사전 설치 구성 요소를 추가해 나가는(BLOAT) 방향과 비슷하게 느껴져서, 많은 사람들이 일반적으로 이를 피하려 합니다. 
이 변경 사항은 구현되기 전에 커뮤니티와 충분히 논의되었을 것으로 생각합니다. 그렇다면 반복적인 답변은 필요 없고, 해당 결정이 어떻게 그리고 왜 내려졌는지 확인할 수 있도록 관련 토론이나 공지사항 링크만 포함해 주시면 감사하겠습니다.
감사합니다!
이 토픽에 있으므로 이미 읽으셨을 가능성이 높습니다:
글쎄, OP의 첫 번째 장에서:
더 일반적인 플러그인 번들링을 통해 더 많은 사이트가 자체 JS 컴파일이 필요 없는 이점을 누릴 수 있으며, 이를 통해 빌드 시간과 리소스 비용을 줄일 수 있습니다.
자체 호스팅, 기본 설치 환경입니다.
일부 플러그인이 이제 번들로 제공되고 있어서 아직 업그레이드 버튼을 누르지 않았습니다. 두렵지는 않아요. 몇 달 전 DB 업그레이드도 무사히 넘겼거든요.
op 목록에 있는 app.yml을 업데이트하는 게 나은가요(물론 먼저 백업은 했죠)? 아니면 UI에서 어떤 플러그인을 제거해야 하는지 알려주는 의미 있는 오류 메시지가 뜨고, 그렇게 조치하라고 중단될까요?
수정: 이미 답변이 있었다면 죄송합니다.
이 grep 명령을 사용하여 재빌드하기 전에 app.yml에서 제거해야 하는 플러그인을 나열할 수 있습니다.
이 플러그인 업데이트 후 이 방법으로 모든 Discourse를 재빌드했는데 실패가 없었습니다.
이것은某种程度上 주제 제목에서 어느 정도 답이 나와 있습니다. '인기’는 흔히 설치되고 사용된다는 것을 의미합니다. '셀프 히스터(자신만의 스타일을 고집하는 사용자)'들을 위해 번들링하는 것은 설치에 시간을 들이지 않아도 된다는 이점이 있습니다. 많은 플러그인과 TC(테마/컨텐츠 팩)가 결국 핵심 프로그램에 통합되었습니다.
이러한 것들을 플러그인으로 시작하는 이점은 개발 기간 동안 소비자 선호도를 테스트하고 기능을 완전히 다듬을 수 있다는 것입니다.
물론 새로 번들링된 코어 플러그인 중 하나도 사용하지 않는 커뮤니티가 다양하게 있을 것입니다. 하지만 더 큰 지표는 아마도 이러한 플러그인들이 설정 후에 설치되는 경우가 많음을 보여줄 것입니다. 또한 유료 호스팅에서 플러그인 사용 및 미사용에 대한 메트릭도 기본적으로 제공됩니다.
재빌드 전에 2개의 플러그인을 놓쳤습니다. 하지만 에러 로그는 이전과 비교하여 문제를 쉽게 식별할 수 있도록 훨씬 개선되었습니다. 이전에는 스크롤을 올려서 문제를 찾아야 했거든요.
데이비드가 언급한 프롬프트는 재빌드 오류이거나 웹 업데이트용 플러그인 페이지에 있을 수도 있습니다.
걱정 마세요. 질문을 올리기 전에 답변이 있는지 확인하는 것은 항상 쉬운 일이 아닙니다.
저도 app.yml을 업데이트했습니다.
주석(comment)을 사용하여 플러그인 제공업체별로 정리하여 정렬하기 쉽게 만들었습니다. 그래도 여전히 다소 번거로웠습니다. 몇 개 위 게시물에서 재빌드 전에 확인할 수 있는 방법을 누군가가 올린 것 같습니다.
댄, 감사합니다. app.yml를 수정하겠습니다.
아니요, 솔직히 말씀드리면 이 글이 공지사항 스레드였기 때문에, 먼저 수정해야 한다는 알림을 받지 못해 업데이트가 실패하자 여기 와서 댓글을 시작했습니다.
그 문제가 해결된 후에는 게시물을 수정하고 문의를 남겼습니다. 하지만 이것이 유일한 공개 토론이라면, 감사히 읽어보겠습니다.
장점은 이해할 수 있지만, 단점도 분명히 있습니다. 따라서 모든 Discourse 포럼 운영자가 플러그인을 선호하지는 않을 것입니다. 그래서 플러그인 설치를 선택 옵션으로 제공했으면 좋았을 것입니다. 예를 들어, 업데이트 시 해당 플러그인 목록을 설치할지 여부에 대한 단일 프롬프트(예/아니오)를 표시하거나… 아니면 관리 영역에 설정이나 알림을 두어, 원할 경우 다음 업데이트 전에 자신의 선호도를 설정하도록 상기시켜 주는 방식 등이었으면 좋았을 것입니다.
날짜별로 어떤 플러그인이 통합되었는지 나열하는 페이지가 있나요? 웹 관리자만 통해 업그레이드를 하다 실패하는 것을 좋아하지 않습니다. 현재 3.5.0.beta9-dev (04dbc622ab) 버전을 사용 중입니다.
업데이트가 설치된 날짜/버전을 나열하는 페이지를 놓쳤을 수도 있습니다. 감사합니다.
Discourse 저장소의 plugins 디렉토리를 살펴볼 수 있습니다.
확인해 본 결과, 여기서부터 시작되는 것 같습니다:
그 중 상당수는 이 페이지에도 있습니다:
이것이 어떻게 작동하나요? 제게는 일부가 기본적으로 활성화되어 있는 것처럼 보입니다.
그러면 이미 플러그인을 가지고 있는 것이죠.
아마도 가장 인기 있는 플러그인이며, 대부분의 사람들이 이미 그 조합 중 일부를 사용하고 있기 때문(본인도 포함)일 것입니다. 이는 '볼트(Bloat)'라고 보기 어렵습니다. 왜냐하면 footprint가 거의 없으며, 어떤 용도로도 이를 사용해야 할 의무가 없기 때문입니다. 이는 윈도우에 원치 않는 20개의 프로그램이 설치되어 있는 것과 매우 다릅니다. 이들은 온/오프 토글(대부분의 사용자는 보지 않을 것이며, 관리자로서는 이미 사용하지 않거나 변경하지 않는 300개의 다른 항목 목록 중 하나에 있을 뿐)이며, 끊임없이 나타나다거나 실제 공간을 차지하거나 기본적으로 무언가를 수행하도록 설정된 것이 아닙니다. 원치 않는 메모장이 기본적으로 설치되어 있으면 결국 두 개의 메모장이 있게 됩니다. 원치 않는 플러그인이 있으면 패널에 옵션이 하나 놓여 있는 것뿐입니다.
또한, 제3자 포럼(또는 끝없는 GitHub)을 뒤져서 심지어 존재하는지도 모르는 것을 찾는 것보다 온/오프 스위치를 가지는 것이 훨씬 쉽습니다. 사실 저는 이 중 일부가 존재하는 것을 처음 인지한 것이 바로 이 때였습니다.
드디어 3.5.0.beta9-dev (df03ef6d05)로 업데이트할 시간을 냈습니다.
저는 셀프 호스팅 표준 설치 환경입니다.
Dan님의 위 조언에 따라 app.yml에서 플러그인 관련 줄을 제거한 후 업데이트 과정을 진행했습니다. 항상 그랬듯이 다른 모든 것보다 먼저 Docker Manager를 업데이트해야 했는데, 이 과정은 정상적으로 진행되었습니다. Docker Manager 업데이트가 완료된 후, 저에게는 새로운(저에게는 처음 보는) 메시지가 표시되었습니다.
이전에 리빌드를 해본 적이 있어 방법을 알고 있었고, putty가 서버에 여전히 연결되어 있어 큰 불편함은 없었지만, UI를 통해 업데이트를 할 수 없다는 사실에 약간 놀랐습니다. 저와 같은 셀프 호스팅 초보자를 위한 주의사항으로 이 글을 올립니다. 그 외에는 업데이트가 잘 진행되어 모든 것이 정상적으로 실행되고 작동합니다. 팀과 커뮤니티에 감사합니다.
해결됨, 토픽 투표, 템플릿의 경우, 말씀하신 대로 플러그인 자체는 활성화되어 있습니다. 하지만 해당 기능이 특정 카테고리에 대해 활성화되기 전까지는 아무런 동작을 하지 않습니다.
호환성을 유지하는 데 더 신경을 써 주셨으면 좋겠습니다. 사이트를 업데이트할 때마다 반나절씩 시간을 낭비하게 만드는 것은 좋지 않습니다. 코드를 조금 정리하는 것이 사람들의 사이트를 깨뜨리고 시간을 낭비하게 할 만큼 가치가 있지 않습니다.
솔직히, 수개월마다 사이트 전체가 깨져서 고치는 방법을 알아내야 하는 상황이 반복되다 보니, 제 전문 분야가 아닌 이런 문제를 해결하는 데 지쳐서 Discourse의 대안을 찾고 있습니다.
불편을 드려 죄송합니다. 다만, 번들 플러그인에서 구체적으로 어떤 문제를 겪으셨는지 잘 모르겠네요.
우리는 업그레이드를 최대한 쉽고 간단하게 진행하려고 노력하고 있지만, 이번과 같은 큰 변화의 경우 마찰이 생기는 것은 불가피합니다. 이번에는 사이트 구성을 수정하는 방법에 대한 구체적인 오류 메시지를 추가하여, 수정 작업을 최대한 간편하게 진행할 수 있도록 했습니다.
제가 생각하기에 이 문제의 핵심 중 하나는 Discourse_docker가 커맨드 라인 재빌드(rebuild)가 필요한 시점을 정확히 파악하지 못한다는 점입니다. 이로 인해 관리자 패널에서 업그레이드 버튼을 클릭하기만 해도 사이트가 쉽게 깨질 수 있습니다. (적어도 제가 사람들이 불평하는 내용을 그렇게 보고 있습니다.)
예전에는 해당 문제를 해결한다는 커밋을 꽤 자주 봤는데, 요즘은 그렇게 많이 보이지 않는 것 같습니다. 저는 Discourse_docker를 직접 많이 사용하지는 않아서(많이?라는 의문도 들지만) 세심하게 주의를 기울이지는 않았습니다.
만약 이 사용자가 UX(관리자 패널)를 통한 업그레이드가 아니라 재빌드를 실행했다면, 다음과 같이 하면 되었을 것입니다.
./launcher start app
그리고 업그레이드는 편리할 때 처리하면 됩니다.