2.8.x에서 3.1.1로 업그레이드한 후, %{base_url}%{url}을 사용하여 주제 링크를 포함하던 기존 템플릿이 모두 무효로 강조 표시됩니다. GUI에서는 다음 보간 키가 유효하지 않습니다: base_url이라고 표시합니다.
하지만 실제로는 유효합니다. %{base_url}을 제거하고 %{url}만 남기면 링크가 깨집니다(도메인 없이 경로만 포함됨). 반면 이를 포함하면 링크가 유효하고 완전한 형태로 표시됩니다.
1개의 좋아요
이것은 이전 버전의 Discourse에서 변경된 사항일 수 있지만, 버그라고 생각하지 않습니다. 이메일 템플릿에서 허용되는 보간 키를 찾는 것은 항상 까다로웠습니다. 이제 사용할 수 있는 키에 대해 설명하는 게시글이 있습니다: Interpolation Keys for Customizing Text and System Email Templates. 허용되는 키 목록은 여기에 있습니다: discourse/app/models/translation_override.rb at main · discourse/discourse · GitHub.
{base_url}은 그 목록에 없습니다.
이미 사이트의 기본 URL을 알고 있으므로, 해당 키가 필요한지 확실하지 않습니다. %{base_url}%{url} 대신 사이트 URL을 그대로 사용하세요. 예를 들어 https://forum.example.com%{url}처럼 사용할 수 있습니다.
2개의 좋아요
하지만 실제로는 작동합니다. 즉, %{base_url}은 정상적으로 확장되므로 잘못된 것이 아닙니다(단순히 GUI가 경고만 하는 것입니다). 또한, 이를 제외하고는 완전히 작동하는 링크를 생성할 수 없습니다(전체 base URL을 하드코딩하는 경우를 제외하면, 이는 권장하지 않는 방법입니다).
플레이스홀더의 일반적인 목적은 소프트웨어를 견고하게 만드는 것이며, 여기에는 하드코딩을 피하는 것이 포함됩니다. Discourse 설치의 도메인 이름, 호스트 이름 또는 경로(base_url의 어떤 요소든)를 변경하면, 이를 하드코딩한 모든 템플릿을 수정해야 합니다. 이는 좋지 않은 코딩 관행입니다.
Discourse 개발은 일반적으로 매우 건강하고 견고한 코딩 관행을 따르는 것으로 알고 있으므로, (1) 템플릿을 검증할 때 base_url을 제거하면서 (2) 실제로는 존재할 경우 해석하고, (3) 좋지 않은 코딩 관행에 의존하지 않고 완전히 작동하는 URL을 생성하는 대안을 제공하지 않는 것은 실수/버그였을 수밖에 없다고 추측할 수밖에 없습니다.
또한, 이는 실질적인 이점을 찾지 못하면서 많은 수작업을 사용자에게 강요하는 큰 역호환성 변경 사항이므로, 버그/실수였다고 가정할 이유가 더 강해집니다.
(3.x 버전에서 텍스트 템플릿과 관련된 다른 버그들도 목격했으므로, 이것이 실수였다고 가정할 이유가 더 많아집니다)
1개의 좋아요
제가 이 부분을 테스트해 보았을 때, %{base_url}이 저장되지 않아 사용되지 않는 상태입니다.
아마도 누락된 부분이 있는 것 같습니다. 오래된 사이트의 기존 이메일 템플릿이 깨질 수 있다는 점에는 동의합니다. 이 이슈를 Contribute > Bug 카테고리로 다시 이동하고, 팀이 이에 대해 어떻게 할지 결정할 수 있도록 하겠습니다.
처음 언급했듯이, 3.x로 업그레이드한 후 기존 사용자 지정 템플릿이 잘못된 것으로 잘못 표시되는 문제에 대해 이야기하고 있습니다. 즉, 2.x에서 편집되어 업그레이드 후에도 여전히 존재하는 %{base_url}을 포함하는 템플릿을 말하는 것입니다. 이 플레이스홀더를 제거하면 하드코딩에 의존하지 않고 전체 URL을 생성하는 것이 불가능해집니다. 제거하지 않으면 3.1.1에서도 여전히 정상적으로 확장된다는 것이 분명해집니다. 첫 번째 게시글을 다시 읽어 봤지만, 불분명한 부분이 보이지 않습니다.
데이터베이스를 직접 편집하거나(또는 코드가 동일한 유효성 검사를 실행하지 않는 경우라면 Rails 콘솔에서도) 직접 테스트해 볼 수 있을 것입니다.
2개의 좋아요
결국 그 문제를 파악했습니다. 제가 직접 테스트해 보지는 않겠지만, 맞으시리라 확신합니다.
2개의 좋아요
이건 버그인 것 같습니다. 아마도 %{url}에는 호스트 이름이 포함되어야 하는 것 같습니다. 엔도 템플릿에서 호스트 이름이 없는 URL은 거의 쓸모가 없거든요(전역적으로 상대 기본 경로를 변경하는 HTML 방식이 있는 경우를 제외하고는요).
팀이 이번 주에 컨퍼런스에 참석하고 있어서, 이 문제에 대한 피드백을 받기까지는 조금 시간이 걸릴 것 같습니다.
1개의 좋아요
그것은 좋은 관행이 아니라고 생각합니다. 그렇게 하면 웹사이트 루트를 참조할 방법이 없게 되거든요. %{base_url}은 URL을 구성할 수 있도록 허용하기 위해 중요한 역할을 수행합니다. 일반적으로 URL 템플릿 시스템은 base, path, full_url이라는 세 가지 플레이스홀더를 제공하며, 마지막 것은 편의를 위해만 제공됩니다(앞의 두 가지를 연결한 것입니다).
1개의 좋아요
@pfaffman 3.2.1에서도 여전히 수정되지 않았습니다. 처음 보고한 이후로 아무것도 변하지 않았습니다. 이 문제를 좀 더 우선순위로 올려서 수정해 주실 수 있을까요? 요약하자면, %{url}은 베이스 URL 이후의 경로만 포함하므로, 거의 모든 템플릿에서 %{base_url}를 사용할 수 있어야 합니다.
적어도 사용 가능 키 목록에 표시되지 않더라도 사용자가 이를 사용할 수 있도록 막지 말아 주세요.
hey @nordize, 여기서 답변을 남긴 사람 중에는 버그 수정에 대한 권한이 있는 사람이 아무도 없습니다.
그래서 그런 경우엔 어떻게 하면 좋을까요? 누구에게 알리거나, 관련 담당자의 주의를 끌기 위해 다른 조치가 가능한지 잘 모르겠어요.
1개의 좋아요
상황을 공유드리면, 엔지니어가 배정되어 이 문제를 확인하고 있습니다. 
누군가 rails 객체 이름이나 rails 콘솔 명령어로 템플릿에서 %{base_url}을 강제하는 방법을 도와줄 수 있나요? 이 템플릿은 해당 변수를 받아들이고 확장하는 것이 확실한데 (단순히 GUI에서 유효하지 않다고 표시하는 것뿐입니다).
안녕하세요, @nordize 님!
스크린샷과 업데이트하려는 템플릿의 키 등 추가 정보를 제공해 주실 수 있을까요? 제 인스턴스에서는 base_url을 사용하는 데 문제가 없지만, 해당 문제가 특정 템플릿과 관련이 있을 수 있습니다.
여기서 %{base_url}이 존재해야 하는 예시를 볼 수 있습니다: Help with Rails console to edit text template
이 외에도 많은 경우가 있습니다(예를 들어 대부분의 이메일 템플릿).
모든 이메일 템플릿(아니면 모든 텍스트 템플릿!)은 어디서든 참조할 수 있는 루트 웹사이트이므로 %{base_url}을 허용해야 합니다. 일부 템플릿에서만 선택적으로 제거한 결정이 이해되지 않습니다 … 물론 그것이 어쩔 수 없이 발생한 실수라면 모를까.
2개의 좋아요
고마워요. 한번 확인해볼게요.
이건 의도적인 게 아닌 것 같아요.
1개의 좋아요