제안된 대로, 저는 기존 포럼을 제자리에 둔 채로 같은 도메인에서 Discourse를 사용하려고 하고 있습니다. nginx를 프록시로 설정하여 Discourse URL과의 충돌을 우회하는 방법을 찾아냈고, 초기 페이지 로드 시(및 SEO 목적)에는 모든 것이 정상적으로 작동합니다.
제 문제는 Discourse 내부에서 해당 기존 링크로 연결하는 것입니다. Discourse 앱 라우팅이 해당 URL을 내부 링크로 간주하여 404 오류를 발생시킵니다. 현재 사용 가능한 도구를 이용해 여러 방법으로 우회를 시도해 보았지만, URL 또는 같은 도메인 환경에서는 아무것도 작동하지 않습니다. (또한 Discourse를 서브폴더에 배치하는 것도 원하지 않습니다.)
nginx에서 수행하는 방식을 모방할 수 있도록 SERVER_SIDE_ONLY 배열에 항목을 추가할 수 있다면 그렇게 작동할 것입니다. 이를 수행하는 방법이나 다른 대안에 대한 제안이 있으신 분은 어떻게 되시나요?
그 토픽에서 권장했던 내용과는 전혀 다릅니다. 새 포럼은 새로운 서브도메인에서 시작하고 기존 포럼은 그대로 두는 것이 좋습니다.
그렇게 생각해도 맞습니다. 정말로 기존 포럼과 새 포럼을 같은 도메인에서 사용하고 싶다면(다시 말하지만, 이미 언급한 문제들을 고려할 때 이는 매우 나쁜 아이디어로 보입니다), 기존 포럼을 가리키는 CNAME으로 설정된 다른 도메인을 하나 더 만들고, Discourse가 해당 도메인으로 링크하도록 구성할 수 있습니다. 이렇게 하면 Discourse가 이를 별개의 서버로 인식하여 링크를 직접 처리하지 않고, nginx가 해당 링크를 받으면 다른 도메인에서 데이터를 서빙하거나 브라우저를 올바른 주소로 리다이렉트할 수 있습니다.
구식 콘텐츠는 archive 서브도메인에 두는 것을 고려해 보았습니다(이 경우 SEO에 부정적인 영향을 미칠 위험이 있습니다). 하지만 여전히 사용자가 제공한 링크를 Discourse가 변경하는 방법은 모든 가능한 페이지에 대해 영구 링크(permalink)를 생성하는 것 외에는 없다고 생각합니다. 아마도 archive 서브도메인 사용이 시간이 지나면 사람들이 이를 알게 되고 브라우저 주소창에서 복사/붙여넣기를 하면서 자연스럽게 자리 잡게 될 것입니다.
단순히 import만 했더라면 해당 항목들에 대해 모두 영구 링크(permalink)가 생성되었겠지만, 그렇게는 큰 도움이 되지 않습니다. 수입(import) 작업을 통해 상당 부분 생계를 유지하는 사람이라면 아마도 이런 생각을 할 것입니다.
가장 쉬운 방법은 새 포럼을 새로운 URL로 이동하는 것입니다(아직 SEO를 크게 해치지 않았기를 바랍니다) 또는 기존 포럼을 다른 곳으로 이동하는 것입니다(기존 콘텐츠의 SEO는 잃게 되지만, 리다이렉트를 수행할 수 있는 영구 링크 정규화(permalink normalization)나 NGINX 마법을 사용할 수 있을지도 모릅니다). 새 사이트가 얼마나 오래 운영되어 왔습니까?
영구 링크 정규화를 만들 수 있을지도 모르지만… 아니요. 영구 링크 정규화는 영구 링크에만 작동하며 외부 URL에는 적용할 수 없다고 생각합니다. 테마 구성 요소가 일치하는 URL을 찾아 가짜/CNAME 호스트명으로 재작성하는 것이 가능할 수도 있지만, 구운(cooked) 게시물에 무엇이 포함되는지(호스트명을 포함한 전체 URL인지, 아니면 쿠킹 과정에서 호스트명이 제거되는지) 확실하지 않습니다.
구운 게시물에 전체 URL이 포함되어 있다면, https://github.com/literatecomputing/runners-onebox-theme에서 제가 하는 것과 같은 작업을 수행할 수 있습니다.
! 404 페이지에서 테마 HTML에 스크립트를 추가하여 처리할 수 있습니다…
404 페이지에서 브라우저 창을 “없음” URL로 새로고침하여 서버 측을 호출하도록 했습니다. 작동합니다! 제가 볼 때 유일한 단점은 리다이렉트가 눈에 띄며, 실제 404 오류가 발생하면 앱에서 벗어나게 되어 사이드바/헤더가 사라진다는 것입니다.
<script type="text/discourse-plugin" version="0.8">
api.onPageChange((url, title) => {
const router = api.container.lookup('service:router');
var is404 = document.getElementsByClassName("page-not-found");
if (is404.length) {
const params = new URLSearchParams(router.currentRoute.queryParams).toString();
let q = "";
if (params){ q = "?"+params; }
window.location.replace(window.location.origin + url + q);
}
});
</script>
이전에 제안했듯이, 클라이언트 측에서 toy가 이를 잡을 수 있어야 한다고 생각합니다. HTML의 구 사이트 링크에 호스트네임이 포함되어 있나요?
네, 전체 URL이 그곳에 있습니다. 테마 컴포넌트를 만드는 방법을 살펴보겠습니다. 감사합니다!
테마 컴포넌트가 생성되었습니다! 이 컴포넌트는 제공된 정규식과 일치하는 경로를 가진 hostname으로 연결되는 모든 href를 찾아, 내부 라우팅을 우회하도록 window.location을 설정하는 click 이벤트를 추가합니다.
호기심이 생기는데, 이 시나리오에서 (인라인) 원박싱이 작동하는지 궁금합니다.
같은 도메인의 URL은 원박스(onebox) 처리가 되며, 일반 링크와 동일한 문제를 겪습니다. 제 테마 컴포넌트는 게시물 내의 모든 <a href 링크에 적용되므로, 원박스 처리된 링크에도 정상적으로 작동합니다.