제 문장에서 중요한 부분은 다음과 같습니다:
말씀하신 대로 업데이트 후 비추천 항목이 오류로 바뀌게 됩니다. 
네, 이 값들은 컴포넌트의 주입된 속성(injected properties)을 통해 접근하거나, discourse/models/user와 discourse/models/site에서 Site 및 User 모듈을 가져와서 접근할 수 있습니다.
5개의 좋아요
아, 네. 헬퍼를 통해 파라미터로 전달하는 것의 유용한 대안이네요.
4개의 좋아요
제가 개발하고 ./bin/ember-cli를 실행 중인 플러그인의 경우, ember-cli를 사용 중이므로 걱정할 필요가 없습니다.
하지만 제 우려는 이 사실을 너무 늦게 알게 될 수십 명, 혹은 수백 명의 사용자들입니다. 자바스크립트를 CSS와 구별하지 못하거나 플러그인과 테마 구성 요소를 구분하지 못하는 사용자들은, 테마 구성 요소에 자바스크립트가 포함된 경우가 아니라면 걱정할 필요가 없습니다.
제가 원하는 것은, 무엇이든 걱정해야 하는지 여부를 확인할 수 있는 간단한 테스트입니다. 그런 사용자들에게는 새 서버를 설정하고 데이터베이스를 복원한 후, 문제가 발생하는지 확인해 보라고 권유할 것입니다. 맞죠?
아니면 EMBER_CLI_PROD_ASSETS: 1을 켜고 다시 빌드한 후, 문제가 발생하면 다시 끄고 새 서버를 설정하여 수정하는 것이 좋을까요?
5개의 좋아요
html 또는 js 타입의 theme_fields가 있는지 확인하는 쿼리를 실행해 볼 수 있습니다:
그 방법도 통하지만, 새 서버를 하나 세팅하는 것은 꽤나 많은 노력인 것 같습니다. 대신, 다음과 같이 권장합니다:
- 개발자 도구 콘솔을 열고 노란색 비권장(deprecation) 알림을 확인하세요
- 해당 문제를 수정하세요
- Ember CLI로 업그레이드하세요 (또는 기본값으로 배포될 때까지 기다리세요)
2개의 좋아요
. . . 지난 1년 동안 새로운 서버를 “쉽게” 띄울 수 있는 도구를 개발해 왔다면 별개의 이야기겠지만요. 
즉, 이런 사항에 관심을 두지 않는 사용자의 경우, 기본값으로 ember가 적용되는 시점이 도래하면 시스템이 깨지게 됩니다. 그리고 그때 ENV 변수를 끄면 한두 달(그리고 당연히 수정 작업) 동안은 버틸 수 있지만, 그 후에는 더 이상 작동하지 않을 것입니다.
4개의 좋아요
Kanban 테마가 활성화된 새 사이트로 백업을 복원했는데 오류가 발생하고 있습니다(이 문제는 kanban 관련 주제에서 보고했습니다). 아래 설정을 시도해 보았지만
EMBER_CLI_PROD_ASSETS: 0
빌드를 다시 실행해도 여전히 다음과 같은 메시지가 표시됩니다:
정기적으로 업데이트해야 하는 이유:
https://github.com/browserslist/browserslist#browsers-data-updating
이 메시지는 ember-cli에서 나오는 것 같다는 인식이 듭니다. 새 사이트에서 이를 비활성화할 방법이 있을까요?
기존 사이트를 다시 빌드하면 새 기본 이미지가 적용되어 ember-cli를 비활성화할 수 없게 될까요?
1개의 좋아요
여기서 메시지에 오타가 있는 건지, 아니면 yml 파일에 오타가 있는 건가요? EMBER_CLI_PROD_ASSETS: 0으로 표기되어야 합니다.
2개의 좋아요
감사합니다! 하지만 네, 오타는 맞아요. 다만 yml 파일에서는 제대로 작성해 두었거든요. 그냥 OP에 복사해서 붙여넣을 때만 정확히 넣은 거예요.
1개의 좋아요
코드에 있는 체크는 변경되지 않은 것으로 보이지만, 저는 Ruby에 대해 잘 알지 못합니다. ENV['EMBER_CLI_PROD_ASSETS']를 사용한 부울 조건문은 해당 키의 값을 사용하게 되나요, 아니면 해당 키가 존재하는 경우에만 true가 되나요?
후자의 경우라면, yml에서 EMBER_CLI_PROD_ASSETS를 0으로 설정하는 것보다 제거하는 것이 해결책이 될 수 있습니다.
1개의 좋아요
그렇게 하면 작동하지 않습니다. 해당 줄을 삭제해야 합니다.
1개의 좋아요
. . . 잠깐 . . .
제 문제는 ember-cli와는 무관했으며, 2컨테이너 설치 환경에서 standalone.yml이 업데이트될 때 web_only.yml이 업데이트되지 않아 제 설정 오류 때문이었습니다. PR을 올렸습니다:
4개의 좋아요
이제 Ember CLI가 모든 Discourse 설치의 기본값이 되었습니다. 다음 업데이트 시( /admin/upgrade UI 또는 ./launcher rebuild app 를 통해) 자동으로 Ember CLI로 전환됩니다.
현재 대부분의 관리형 호스팅에서 Ember CLI를 사용하고 있으므로 큰 문제는 없을 것으로 예상됩니다. 하지만 이상한 점이 발견되면 Meta에서 주제를 만들어 주시면 조사하겠습니다.
7개의 좋아요
어제 Ember CLI 문제로 실패한 사이트를 재구축했고, EMBER_CLI_PROD_ASSETS=1을 제거하여 문제를 해결했습니다.
초기에 Ember CLI를 비활성화하기 위해 EMBER_CLI_PROD_ASSETS=0으로 설정해 보았는데, 여전히 ember_cli가 포함된 것 같았습니다. 누군가 0으로 설정한다고 해서 비활성화할 수 없다고 알려주었고(이해가 가지 않았지만 사실인 것 같았습니다).
이는 오래된 테마를 사용하고 JavaScript 콘솔을 거의 확인하지 않는 자체 호스팅 사용자에게 다소 까다로운 문제입니다.
2개의 좋아요
사실이 맞았지만, 최신 커밋으로 로직을 수정하여 =0이 의도한 대로 작동하도록 했습니다. 다만, 몇 주 안에 ‘레거시’ 환경을 완전히 제거할 계획이므로, 매우 단기적인 용도가 아니라면 =0을 사용하지 마세요.
우리 호스팅 환경에서 확인된 가장 흔한 오류들에 대해 하위 호환성을 추가했습니다. 예를 들어, 몇 주 전 이 커밋에서는 Discourse.User와 Discourse.SiteSettings에 대한 하위 호환성을 추가했습니다. 이 커밋은 비표준 초기화 프로세스를 가진 테마의 일부 문제를 수정했습니다.
이번 롤아웃을 최대한 원활하게 진행하기를 원하므로, 지난 1주 정도 사이에 오류를 겪으셨다면 정확한 오류 내용과 해당 오류를 유발한 코드를 알려주시기 바랍니다.
6개의 좋아요
아, 축하드립니다. 이제 말이 되네요. (처음부터 그렇게 작동할 거라고 생각했던 대로 작동하네요. 그리고 제가 그렇게 작동할 거라고 생각했던 것과 다르게 작동한다고 들은 기억이 있는데, 제 기억이 틀린 건 아니었네요. 정말 다행입니다!).
그걸 파악하는 게 정말 어렵습니다 (아마도 제 무지에서 오는 문제일 겁니다). 오류 원인을 보여줄 거라고 생각되는 부분을 클릭하면, 오류를 일으키는 코드 대신 오류를 테스트하는 코드가 보입니다. 곧 예시를 보내드리겠습니다.
3개의 좋아요
해결에 도움이 필요하시다면, 오류 화면 캡처를 첨부한 Support 토픽을 만드는 것이 좋은 출발점이 될 것입니다. 그러면 거기서 디버깅을 도와드릴 수 있습니다. 비슷한 오류를 경험한 다른 사람이 있을 가능성이 높으며, 그 증상을 알아볼 수 있을지도 모릅니다. 
7개의 좋아요
그리고 이 사건의 마지막 단계: 레거시 빌드 시스템이 이제 비활성화되었습니다. 모든 Discourse 설치에서 자산(assets)은 Ember CLI를 사용하여 컴파일됩니다.
이 변경 사항은 설정에서 EMBER_CLI_PROD_ASSETS=0을 의도적으로 설정했던 사용자들에게만 영향을 미칩니다. 이 경우 빌드 중에 경고가 출력되고, Ember CLI가 사용됩니다.
12개의 좋아요