안녕하세요 여러분,
답변을 찾기 위해 몇몇 스레드를 살펴봤고, 많은 정보를 찾았습니다(아래 링크 참조 — 감사합니다!). 덕분에 원하는 모습으로 거의 설정할 수 있게 되었습니다. 하지만 아직 해결하지 못한 질문이 하나 있습니다.
이것은 임베드 에셋 파일, 특히 embed_HASH.css 파일에 관한 것입니다.
이 에셋이 빌드될 때 활성 테마의 색상 팔레트를 사용하여 컴파일되지 않는 것처럼 보입니다. 이것이 의도된 동작일 수도 있고, 제가 놓친 부분이 있을 수도 있습니다.
다음에 대해 명확한 답변을 듣고 싶습니다:
embed_[digest].css는 항상 기본 팔레트로 빌드되는 건가요?
그렇다면 그 점은 받아들일 수 있습니다 — Discourse에서 테마와 색상 팔레트 처리 방식을 개선하기 위한 많은 작업이 진행 중이라는 것을 알고 있습니다.
- 커스텀 팔레트로 빌드할 수 있다면, 그 동작을 트리거하는 방법은 무엇인가요?
- 시스템의 라이트 또는 다크 팔레트로 빌드될 수 있다는 것을 확인했습니다. 따라서 커스텀 팔레트 사용도 가능해 보이지만, 라이트 또는 다크 임베드 파일을 예측 가능하게 생성하는 방법을 찾지 못했습니다.
이를 테스트하기 위해 모든 테마와 팔레트를 삭제하고, 모든 것을 기본 라이트 테마로 되돌린 다음 다음을 실행했습니다:
rake assets:precompile
rake assets:precompile:build
…라이트 테마의 embed_HASH.css를 얻을 것으로 기대했습니다. 하지만 결과는 여전히 다크 스타일을 사용하는 것으로 보였습니다.
내부 구조에 대해 깊이 숙지하지 못했기 때문에 자명한 것을 놓치고 있을 수 있습니다. embed_HASH.css가 예측 가능한 팔레트로 빌드되도록 필요한 사항이 있다면 공유해 주시면 정말 감사하겠습니다.
미리 감사합니다!
참고로, 제 Discourse 인스턴스는 Docker에서 실행 중이며 최신 상태입니다. launcher 스크립트와 standalone 템플릿을 사용했습니다.
관련 읽을거리 (신규 계정은 링크 2개만 허용되며, 3번째는 검색 가능한 제목입니다):
나만의 질문에 대한 부분적인 답을 찾았고, 이 통찰력을 공유하고 싶습니다:
embed_[digest].css 파일은 실제로 활성 테마에서 선택된 색상 팔레트를 사용하여 빌드됩니다.
제가 깨달은 바에 따르면, 문제는 매우 공격적인 HTTP 응답 캐싱 때문입니다.
여전히 누군가가 답해 주었으면 하는 것은 다음과 같습니다:
Discourse에서 자산 파일의 HTTP 응답은 어디에 캐시됩니까?
이것은 브라우저 측 캐싱만이 아닙니다 — 서버 측에서도 캐싱되는 것으로 보입니다.
Rails 프로덕션 로그를 테일링(tailing)하면, 새롭고 이전에 본 적 없는 쿼리 파라미터 세트를 가진 요청만 새로운 자산 렌더링을 트리거하는 것을 관찰할 수 있습니다:
$ tail -n 50 shared/standalone/log/rails/production.log -f
Started GET "/stylesheets/embed_afe162195ad0a7185309a19d8c36036d2e53708c.css?__ws=domain.tld&foo=bif" for fd00:aaaa::f1a at 2025-06-27 01:14:38 +0000
Processing by StylesheetsController#show as CSS
Parameters: {"__ws"=>"domain.tld", "foo"=>"bif", "name"=>"embed_afe162195ad0a7185309a19d8c36036d2e53708c"}
Sent file /var/www/discourse/tmp/stylesheet-cache/embed_afe162195ad0a7185309a19d8c36036d2e53708c.css (0.2ms)
Completed 200 OK in 22ms
그 후, 동일한 URL에 대한 모든 후속 요청(쿼리 문자열이 달라도)은 동일한 응답을 반환합니다 — 기본 테마가 변경되었더라도 마찬가지입니다.
예를 들어:
https://domain.tld/stylesheets/embed_[digest].css?__ws=domain.tld
https://domain.tld/stylesheets/embed_[digest].css?__ws=domain.tld&foo=bar
나는 고유한 쿼리가 사용되는 첫 번째 경우에만 업데이트된 테마 스타일을 확인합니다. 동일한 매개변수를 가진 모든 향후 요청은 재컴파일 후에도 이전 버전을 서빙합니다.
launcher 스크립트는 기본적으로 RAILS_ENV=production을 사용합니다. 저는 이를 그대로 두었습니다. 개발 중에 캐싱을 완전히 비활성화하기 위해 RAILS_ENV=development로 전환해 볼 수 있지만, 이상적으로는 다음 사항을 알고 싶습니다:
프로덕션 환경에서 자산 응답의 HTTP 레벨 캐싱을 어떻게 삭제하거나 비활성화할 수 있습니까?
누군가 Discourse가 이러한 자산 응답을 어떻게 캐싱하는지 — 또는 이를 올바르게 무효화하는 방법 — 에 대한 통찰력을 가지고 있다면 정말 도움이 될 것입니다.
아, 진짜
Nginx 때문이었어!
요약:
rm -rf /var/nginx/cache/*`
즉시 해결!
선택 사항: Nginx 자산 캐싱 비활성화
다음 파일을 편집하세요:
/etc/nginx/conf.d/discourse.conf
243~246번 줄 근처에서 캐싱 지시문을 주석 처리하세요:
# proxy_cache one;
# proxy_cache_key "$scheme,$host,$request_uri";
# proxy_cache_valid 200 301 302 7d;
# proxy_cache_bypass $bypass_cache;
그 다음 Nginx를 재시작하세요:
sv restart nginx
색상 팔레트를 변경하는 경우…
테마의 색상 설정만 편집해서는 embed_[digest].css가 재생성되지 않습니다. Discourse가 새로운 자산 파일을 생성하도록 하려면 다음을 수행하세요:
rm tmp/stylesheet-cache/* # 또는, 임베드만 해당될 경우 `rm tmp/stylesheet-cache/embed*`
RAILS_ENV=development는 어떻게 되나요?
RAILS_ENV: development를 설정하면 캐싱이 비활성화될 것이라고 생각할 수 있지만:
- Discourse가 사용하는
nginx.sample.conf는 환경과 관계없이 기본적으로 캐싱이 활성화되어 있습니다
- 해당 캐싱은
RAILS_ENV와 연결되어 있지 않으므로, 임베드된 자산 캐싱 문제를 해결하는 데 도움이 되지 않습니다
따라서 Nginx 계층을 완전히 재구성할 계획이 없다면, 캐시를 수동으로 지우거나 해당 줄들을 비활성화하면 됩니다. 프로덕션으로 전환할 준비가 되면 되돌릴 수 있습니다.
./launcher rebuild standalone은 어떻게 되나요?
네, 작동합니다. 하지만 테마를 능동적으로 조정하고, 임베드를 테스트하며, 색상을 미세 조정하는 중이라면… 매번 몇 분을 기다리는 것보다 더 빠른 방법이 필요할 것입니다.
더 나은 개발 환경 설정이나 빠른 해결책이 있나요? 참여해 주세요!