기술 스택을 단순화하기 위해 웹사이트와 포럼을 따로 호스팅하는 대신, Discourse를 재구성하여 웹사이트와 포럼을 하나로 통합하는 것이 나을지 고민하고 있습니다.
@angus 님의 Pavilion이 Discourse를 이렇게 활용하고 있는 것으로 보입니다.
다만, 저희 웹사이트의 요구사항은 좀 더 복잡합니다. 현재 저희 웹사이트는 다음과 같습니다.
Discourse만으로 구축된 다른 웹사이트들이 있는지 궁금합니다. 참고할 수 있는 사례가 있거나, 이 목표를 달성하기 위한 아이디어가 있으시면 알려주시면 좋겠습니다.
글이 아닌 콘텐츠에는 페이지 게시 기능을 사용할 수 있습니다.
그 다음, 헤더 서브메뉴 플러그인을 사용해 서브메뉴가 있는 상단 메뉴를 만들거나, 다른 플러그인을 사용해 서브메뉴 없이 메뉴만 표시할 수 있습니다.
모든 것은 요구 사항에 따라 달라집니다.
네! 좋은 시작이라고 생각합니다.
우리의 요구 사항 중 하나는 뉴스레터 구독 양식이나 기부 양식과 같은 것을 임베드할 수 있어야 한다는 것입니다.
페이지 발행 시 커스텀 스타일링이 얼마나 강력한지 나도 정확히 잘 모르겠어요. 다른 배경색을 가진 콘텐츠 블록 등 훨씬 더 스타일링된 페이지의 예시가 있을까요?
문제는 결국 세 가지로 요약됩니다:
적절한 캐싱과 CDN을 갖춘 5달러짜리 VPS에서 WordPress를 실행하면 수백만 페이지뷰를 처리할 수 있습니다. 동일한 규모의 Discourse 인스턴스는 훨씬, 훨씬 더 비쌉니다.
트래픽과 활동의 대부분이 Discourse 내에서 이루어지고 정적 페이지로의 트래픽 급증 위험이 없다면, 모든 것을 Discourse 내에서 호스팅하는 것이 합리적일 수 있습니다. 다른 경우에는 여전히 적절한 CMS가 최선의 선택입니다.
15개의 게시물이 새 주제로 분리되었습니다: SSL 인증서가 메인 Discourse 사이트에서 작동하지 않음
디스코urs는 Rails 백엔드를 기반으로 확장성이 뛰어나므로, Rails 앱으로 할 수 있는 거의 모든 것을 할 수 있다고 생각했습니다. 하지만 여러분은 만능 해결책을 찾고 계신 건가요?
물론 그렇게 할 수도 있고, 조직의 상황에 따라 적절할 수 있지만, 저희 Discourse는 메인 웹사이트에 다른 소프트웨어를 사용하고 있습니다.
저희 메인 웹사이트는 https://jekyllrb.com/으로 생성된 정적 HTML이며, 블로그는 간단한 WordPress 인스턴스입니다.
결국 조직의 엔지니어링 구조와 필요 사항 및 우선순위에 따라 달라집니다.
그렇게 해줘서 고마워, Rafael.
나는 WordPress를 내 삶에서 완전히 제거하고 싶어. 처음에는 Discourse 단독 솔루션을 사용하려 했었지만, 지금은 www.literatecomputing.com에 있는 정적/정보성 콘텐츠는 Jekyll로 처리하고, 수익을 내는 부분만 Discourse로 이관하는 방안을 고려 중이다. 그리고 곧 나올 discourse-subscriptions 플러그인도 함께 사용할 계획이다. 현재 나는 설치, 업그레이드 및 기타 유지보수를 담당하는 내 도구의 프론트엔드 역할을 할 Discourse 플러그인을 필사적으로 개발하고 있어.
참고로, Discourse로만 완전히 만들어진 두 웹사이트를 소개합니다. (첫 번째 웹사이트는 이제 더 이상 사용되지 않는 Docuss 플러그인을, 두 번째 웹사이트는 DiscPage 플러그인을 사용합니다.)
이러한 의사결정 프레임워크를 제공해 주셔서 감사합니다!
솔직히 말씀드리자면 이 말의 정확한 의미를 잘 모르겠어서, 이제 이 문제를 우리의 기술 담당자들에게 넘기겠습니다. 
@pfaffman 이 부분에 대해 더 말씀해 주실 수 있나요? 어떤痛点(pain points)가 있으신가요? 저는 여전히 CMS를 고려하고 있으며 WordPress는 상위권에 있습니다.
이 주제에 대해 지속적으로 소통하는 데 매우 관심이 있습니다!
네, 바로 제가 필요했던 것이었습니다. 감사합니다!
솔직히 말하면, PHP가 지금의 이름으로 불리기 전에 배우고 나서 현대적인 언어로 발전한 PHP를 계속 따라가지 못했습니다. 그리고 제 요구 사항은 매우 구체적입니다(돈을 받고, Digital Ocean 드롭렛이 생성되고 그 위에 Discourse가 설치되도록 작업을 수행해야 합니다).
하지만 최근 몇 번에 걸쳐 500~1000달러를 받고 Discourse나 WordPress 관련 간단한 튜닝 작업을 맡았을 때, 빠르고 쉬운 돈이 될 거라고 확신했는데 결국 후회했습니다. 가장 최근에는 시간을 많이 들인 끝에 결국 고객의 돈을 돌려주었습니다. 물론 쉬운 작업이었다면 저를 고용하지 않았을 것입니다. 또한 WordPress 사이트에서 수없이 많은 오래되고 업데이트할 수 없는 플러그인을 가진 다른 고객도 있습니다. 그 사이트는 엉망진창이었고, 어딘가에서 해킹을 당해 포르노 링크가 잔뜩 들어 있습니다. 충분히 피할 수 있는 일이었습니다.
반면, 지난 1년 정도는 WooCommerce 대신 Gravity Forms를 사용해 왔고, 일회성 결제와 구독 결제 모두를 처리하는 데 꽤 만족하고 있습니다(Discourse와 연동되지는 않지만요). (하지만 제가 원하는 시점에 정확히 Discourse 설치를 트리거하도록 설정하는 것은 아직 못 하고 있습니다!)
“표준적인” 작업을 하고 잘 지원되는 플러그인을 고수한다면 후회하지 않을 가능성이 높습니다(다만, Discourse 구독은 discourse-subscriptions 플러그인으로 처리하는 것이 좋습니다). 인터넷 사이트의 4분의 1이 WordPress를 사용하는 데는 그만한 이유가 있습니다.
업데이트: 웹사이트와 Discourse를 각각 다른 두 개의 시스템으로 운영하기로 결정했습니다. 핵심 요인은 웹사이트 콘텐츠를 업데이트해야 하는 사람들이 대부분 비기술 인력이어서, 사용하기가 매우 쉬운 콘텐츠 관리 시스템(CMS)을 사용하는 것이 큰 도움이 되기 때문입니다. Weebly를 사용하여 콘텐츠 업데이트를 쉽게 할 수 있게 했지만, 그보다 더 좋은 점은 기부 플랫폼과 연락처 관리 시스템을 제공하며, 웹사이트 테마, 구성, 임베드 등 더 복잡한 변경 사항을 이메일 한 통으로 요청할 수 있는 전용 기술 팀이 포함된 플랫폼에 비용을 지불하고 있다는 점입니다. 이 팀은 Weebly 사이트는 관리하지만 Discourse는 관리하지 않습니다.
이제 두 개의 다른 사이트를 운영하기로 결정했으니, 두 사이트를 어떻게 일관성 있게 통합할지 고민해야 합니다. @angus 님께 감사의 말씀을 전하고 싶습니다. @angus 님의 회사가 PianoGroove 커뮤니티를 지원하고 있는데, 제가 지금까지 본 통합 중 가장 아름다운 통합을 구현해 주셨습니다(많은 것을 봤지만요!)
PianoGroove 커뮤니티 사이트 스크린샷
@angus 님, 클라이언트를 위해 해주시는 놀라운 작업과, 여러분이 만든 플러그인과 테마를 오픈소스로 공개해 주시는 너그러움에 진심으로 감사드립니다. 우리 웹사이트와 Discourse가 우리에게 적합한 형태로 작동하도록 만들기까지는 아직 갈 길이 멀지만, 매번 Pavilion의 작업이 오픈소스 기반의 grassroots 커뮤니티 조직인 우리에게 정확히 필요한 것이란 점을 깨닫게 됩니다.
debryc님, 감사합니다 
한 가지를 더 덧붙이자면, 우리의 작업을 유지보수하는 사람은 저뿐만 아니라 Pavilion의 모든 멤버들입니다. 우리의 협동조합은 팀워크의 결과물입니다.
또한 우리가 Landing Pages 플러그인을 오픈소스로 공개했다는 점도 언급하고 싶습니다. 이 플러그인은 Discourse 인스턴스를 백엔드로 사용하는 완전히 독립적인 페이지를 만들 수 있게 해주며, 이 주제에서 논의된 요구 사항을 충족하는 또 다른 방법입니다. 이 플러그인은 페이지의 프론트엔드를 Discourse 클라이언트와 분리하여(즉, Discourse 앱을 로드하지 않도록) 처리하되, 공통 백엔드(즉, Discourse 서버)를 통해 쉬운 통합을 허용합니다.
우리는 이미 이 플러그인을 사용하여 일부 클라이언트에게 여기서 논의된 것과 유사한 요구 사항을 충족하기 위한 작업을 시작했습니다. 또한 커뮤니티와 연관된 CMS의 일반적인 사용 사례를 기반으로 한, 해당 플러그인과 함께 사용 가능한 페이지의 쉽게 사용할 수 있는 일반화된 오픈소스 패키지를 개발하는 것도 검토하고 있습니다.
다음은 우리가 이러한 처리를 받을 것으로 예상하는 현재 사용 사례 목록입니다.
블로그(현재 이 부분을 작업 중입니다). Discourse에서 콘텐츠를 작성한 후, 실제 블로그(예: Wordpress나 Ghost처럼)처럼 테마를 적용할 수 있는 완전히 독립적인 블로그 페이지로 이를 제공합니다.
제품, 서비스 또는 기능 페이지(예: 우리의 페이지). Discourse 인스턴스 내의 콘텐츠나 데이터(카테고리, 태그, 주제, 사용자 등)를 포함할 수 있는 제품, 서비스 또는 기능을 표시합니다.
“팀” 페이지(예: 우리의 페이지). Discourse 사용자 그룹의 멤버십(및 사용자 데이터)을 사용하여 팀을 소개하는 페이지입니다.
이벤트 페이지. Discourse 인스턴스 내의 이벤트 데이터를 스타일링된 이벤트 랜딩 페이지에 나열하고 표시하기 위한 것입니다. 여기서 "이벤트 데이터"란 Discourse Calendar 플러그인 데이터, 카테고리, 주제, 사용자(예: RSVP), 위치(우리의 Locations 플러그인 사용)의 조합일 수 있습니다.
우리는 사람들이 이 방식으로 혜택을 볼 것이라고 생각하는 다른 일반화된 사용 사례에도 관심이 있습니다. 이 단계에서 이러한 처리를 덜 받을 가능성이 있는 몇 가지 사용 사례를 이미 고려해 보았다는 점도 언급하고 싶습니다:
상점. 상점의 요소를 통합하는 페이지가 있을 수 있지만, 온라인 상점은 WooCommerce나 Shopify와 같은 전용 솔루션이 항상 요구하는 방대한 기능 집합이 필요합니다.
지식 베이스. 이 요구 사항은 Knowledge Explorer 플러그인과 같은 솔루션에 의해 이미 잘 충족되고 있습니다. 랜딩 페이지가 지식 베이스의 하위 집합을 표시할 수는 있지만, Knowledge Explorer 플러그인(또는 단순히 Discourse 주제 목록)의 기능을 완전히 재현하는 것은 역효과가 날 것입니다.
우리는 이러한 페이지를 개발하려는 누구와도 협력하는 데 관심이 있습니다. 이는 개발 프로젝트 자체로서(예: 스킬 향상), 커뮤니티를 위해, 또는 심지어 판매를 목적으로 할 수 있습니다. 우리는 중기적으로(4~6개월 내) 각 사용 사례에 대해 자체 무료 오픈소스 패키지를 출시할 계획입니다.
Landing Pages 플러그인과 Pavilion의 자체 페이지는 항상 100% 오픈소스이고 무료일 것입니다. 그러나 이는 HTML과 CSS 지식이 있는 누구나 "페이지 팩"을 개발할 수 있는 일반화된 구조입니다. 곧 해당 플러그인의 지식 문서에 "개발자 가이드"를 추가할 예정입니다.
Landing Pages 플러그인은 이미 Discourse 테마 시스템이 프라이빗 리포지토리에 페이지를 호스팅하는 방식과 동일한 방식으로 이를 지원합니다(실제로 백엔드에서는 Discourse 테마 시스템에 기반하여 이를 확장합니다). 이는 원한다면 랜딩 페이지 팩에 대한 접근 권한을 판매할 수 있음을 의미합니다. 이는 다른 개발자들이 이러한 팩을 구축하도록 유인할 수 있습니다.
이 방식은 포럼과 연관된 콘텐츠 관리의 모든 요구 사항을 해결하지는 못하지만, 특히 더 작고 독립적인 커뮤니티에서 정기적으로 확인되는 요구 사항의 하위 집합을 잘 충족할 수 있습니다. 이는 별도의 인스턴스가 필요 없게 하고, 특히 인증 프로토콜(로그인 시 사용자 데이터 공유), 웹훅 또는 기타 데이터 공유 방법을 통해 해당 인스턴스 간에 데이터를 공유할 필요성을 제거하기 때문입니다.
이는 상대적으로 제한적이거나 특정된 콘텐츠 또는 정적 페이지를 포럼과 함께 관리하려는 더 작은 커뮤니티의 경우 비용과 관리 부담을 줄이는 데 도움이 될 수 있습니다. 이는 Wordpress나 기타 CMS 시스템의 직접적인 대체재는永远不会 될 것이지만, 특정 사용 사례를 훨씬 더 쉽게 만들 수 있기를 바랍니다.
네! 감사합니다!
저는 Discourse 기반 커뮤니티에 2.5개월째 참여하고 있습니다. 제가 겪은 문제는 스크립트 포함이 필요한 특정 도구에 대한 필요성이었습니다.
캘린더 예시: 페이지에 삽입할 수 있는 캘린더나 이벤트 도구가 있습니다. 하지만 에 스크립트가 필요하고, 해당 페이지에서 스크립트가 트리거되도록 설정해야 합니다.
더 일반적인 SAS(서버 측 광고링): 많은 경우 iframe이 이상적인 해결책이 아닙니다. 예를 들어, 회원들이 다른 사이트로 이동하여 옵트인(Opt-in)을 해야 하는 상황은 원하지 않습니다. 하지만 제 옵트인 서비스인 ConvertBox에는 스크립트와
커뮤니티의 제공 서비스를 강화해 나가면서, 스크립트 기반 임베드를 더 쉽게 추가할 수 있는 능력을 '해결’하기 전까지는 OneBox가 지원하는 것이나 iFrame 사용에 국한된 느낌을 지울 수 없습니다. 만약 이러한 제어 및 트리거 기능을 제공하는 향상된 페이지 기능이 있다면, 제 WordPress 사이트를 폐지할 수도 있을 것 같습니다.
저는 코딩을 할 수 없지만, 커뮤니티가 이러한 개발의 혜택을 누릴 수 있도록 재정적으로 지원할 의향이 있습니다. 감사합니다!
Discourse UI(예: 토픽 목록 위)에서는 테마를 사용하여 임베드가 실제로 가능하며, Landing Pages 플러그인에서도 가능합니다. 후자의 경우, 이 작은 공룡 게임 버전을 사용하여 예시를 만들었습니다. 여기서 플레이할 수 있습니다: Pavilion (데스크톱 전용).
이것에는 코딩이 필요하지 않았습니다. 제가 한 일은 해당 에셋을 우리의 CDN으로 업로드하는 것(DigitalOcean 'space’에 폴더를 드래그 앤 드롭)이었습니다. 그리고 경로가 "dinosaur"인 페이지를 만들고 이 HTML을 복사/붙여넣기했습니다(모두 관리자 UI를 통해 수행).
<div class="landing page dinosaur">
<div class="container">
<h1>Dinosaur Game!</h1>
<canvas id="game" height="200" width="800"></canvas>
<p class="controls">press space bar to start</p>
<script src="https://pavilion-assets.nyc3.digitaloceanspaces.com/dinosaur/js/helpers.js"></script>
<script src="https://pavilion-assets.nyc3.digitaloceanspaces.com/dinosaur/js/objects/game-object.js"></script>
<script src="https://pavilion-assets.nyc3.digitaloceanspaces.com/dinosaur/js/objects/cactus.js"></script>
<script src="https://pavilion-assets.nyc3.digitaloceanspaces.com/dinosaur/js/objects/dinosaur.js"></script>
<script src="https://pavilion-assets.nyc3.digitaloceanspaces.com/dinosaur/js/objects/background.js"></script>
<script src="https://pavilion-assets.nyc3.digitaloceanspaces.com/dinosaur/js/objects/score.js"></script>
<script src="https://pavilion-assets.nyc3.digitaloceanspaces.com/dinosaur/js/game.js"></script>
<script>
new Game({
el: document.getElementById("game")
});
window.onkeydown = function(e) {
return e.keyCode !== 32;
};
</script>
</div>
</div>
Landing Pages 플러그인은 Discourse의 CSP 및 CORS 설정을 구현하며, 저는 이미 관련 사이트 설정을 통해 CDN에서 스크립트를 처리하도록 설정해 두었습니다.
다음 주에는 해당 플러그인에 대해 이 사용 사례를 다루는 “에셋 호스팅 및 임베드 방법” 지식 베이스 토픽을 게시할 예정입니다.
