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 시스템의 직접적인 대체재는永远不会 될 것이지만, 특정 사용 사례를 훨씬 더 쉽게 만들 수 있기를 바랍니다.