혼란과 어려움의 원인은 Index Topic이 특정 형식을 따라야 한다는 점인데, 이는 문서에서 (완전히 명확하게) 명시되어 있지 않기 때문일 수 있습니다. (최상위 게시물)
저는 이 플러그인을 직접 설치하여 설명을 꼼꼼히 따랐지만, @dennisjbr 님이 겪은 것과 정확히 동일한 방식으로 작동하지 않았습니다.
Meta 예시를 링크하는 것보다 필요한 Markdown의 예를 보여주는 것이 도움이 될 수 있습니다. 왜냐하면 핵심 규칙은 Markdown의 번호/불릿 리스트가 반드시 있어야 한다는 것이기 때문입니다. 문서에는 '리스트’라고만 되어 있지만, '리스트’라는 단어는 일반 영어 용법상 Markdown이 아닌 리스트를 포함할 수 있습니다!
다음은 Index Topic으로 작동합니다:
* https://meta.discourse.org/t/discourse-doc-categories/322376
* Some Arbitrary Text: https://meta.discourse.org/t/discourse-doc-categories/322376
다음은 작동하지 않습니다:
https://meta.discourse.org/t/discourse-doc-categories/322376
Some Arbitrary Text: https://meta.discourse.org/t/discourse-doc-categories/322376
이 외에도 Markdown 헤딩을 사용하여 섹션을 만들고 여러 개의 리스트를 사용할 수 있지만, Markdown 리스트가 없다면 사이드바에 아무것도 표시되지 않습니다. 이것이 다소 자명하고 다른 사람들을 혼란스럽게 하지 않았을 수 있다는 점은 인정합니다. 하지만 저에게는 (멍청하게든, 그렇지 않든) 함정이었고, 저는 Discourse, TC, 플러그인에 대해 초보자가 아닙니다.
초보자인데 미리 양해 부탁드립니다! 꽤 오랫동안 혼자서 해결책을 찾아보고 있지만 어디에서도 답을 찾을 수 없네요.
저는 이 플러그인을 카테고리 수준에서 개별 사용자 프로젝트를 정리하는 용도로 사용하려고 합니다.
우리는 다양한 사용자 프로젝트가 포함된 포럼을 만들고 있습니다. 원래는 모든 프로젝트를 “projects” 카테고리 아래에 두었기 때문에, 누군가가 projects를 클릭하면 모든 개별 프로젝트가 나열된 하위 카테고리 박스들을 깔끔한 UI로 확인할 수 있었습니다(일종의 프로젝트 마켓플레이스처럼).
하지만 그렇게 하면 개별 프로젝트가 카테고리 대신 하위 카테고리로 시작하게 되어 데이터 조직의 한 수준을 잃게 됩니다.
이 플러그인을 발견했을 때 정말 흥분했습니다. 모든 프로젝트를 카테고리 수준에서 정리할 수 있어 프로젝트 내부에서 더 나은 데이터 조직을 만들 수 있으리라 생각했기 때문입니다.
그래서 이제 개별 프로젝트를 개별 카테고리(예: 낚시 루어, 프로젝트 2, 프로젝트 3)로 만들고, doc categories 플러그인을 사용하여 모든 프로젝트의 목차(ToC)를 기본적으로 생성하고 있습니다. 이렇게 하면 사람들이 doc cat 플러그인으로 실행되는 새로운 projects 카테고리를 클릭하고, 드롭다운 메뉴를 통해 우리가 인덱스 토픽에 나열하기로 선택한 하위 카테고리와 토픽을 탐색할 수 있습니다.
카테고리가 중앙 열에 표시되어, 일반 Discourse 피드의 “모든 카테고리” 페이지와 유사한 뷰를 만들 수 있는 방법이 있을까요?
projects doc 카테고리를 클릭했을 때 왼쪽 메뉴에 모든 프로젝트가 나열되도록 하되, 메인 피드에서도 하위 카테고리처럼 박스 형태로 표시되기를 원합니다. 이 게시물에는 이미지만 한 장 첨부할 수 있어서 왼쪽 메뉴의 프로젝트 이미지를 첨부했는데, 제 토픽 게시글이 표시되는 중앙 부분에 카테고리 박스가 표시되기를 원합니다.
휴, 감사합니다!
여러분이 서브카테고리(subcats)를 위해 하고 있는 일은 올바른 방향을 향해 가고 있는 것 같습니다. 하지만 저는 주로 UI에서 중간 열의 상자에 서브카테고리와 마찬가지로 카테고리(Categories)가 표시되도록 하고 싶었습니다.
결국 서브-서브카테고리(sub-sub-cat) 플러그인을 찾아서 설치했습니다. 이제 이 플러그인을 사용해 서브카테고리를 그룹화하고 있습니다. 서브카테고리 아래에 서브-서브카테고리와 토픽이라는 두 단계의 데이터 분배가 있기 때문에, 서브카테고리가 실제로 ‘카테고리’ 역할을 하게 되었습니다.
이것은 사용자 프로젝트 내에서 데이터 분배와 조직화 수준을 높이라는 제 주요 목표를 충족시켰습니다. 이제 저는 서브-서브카테고리와 플러그인을 함께 사용해 스텁 카테고리(stub category) 수준에서 두 가지의 장점을 모두 얻고 있습니다.
처음에는 덕 카테고리(duck categories) 플러그인만으로 프로젝트 카테고리를 만들려고 했으나, 왼쪽에 메뉴만 있고 사용자가 탐색할 중간 영역이 비어 있는 UI가 마음에 들지 않았습니다. 그래서 (카테고리인) 프로젝트들이 서브카테고리가 보통 하듯이 ‘카테고리(모든 프로젝트)’ 내에서 표시되도록 하고 싶었습니다. (마지막 게시물에 있는 목업 사진 참고)
기존 플러그인에서는 태그를 관리하기만 하면 어떤 카테고리에든 문서를 둘 수 있었습니다. 그런데 이제는 모든 문서 주제가 단일 카테고리 아래에 있어야 하는 것 같습니다. 맞나요? 그렇다면 컨텍스트를 잃는 셈이죠. 일부(기존) 문서는 특정 그룹/카테고리(예: 스태프만 접근 가능)에 속해 있기 때문입니다.
두 접근 방식의 차이점, 왜 이 방식을 선택했는지, 그리고 레거시 플러그인과 새 플러그인 사이의 격차를 어떻게 해소할 계획인지 명확히 설명해 주실 수 있을까요?
또한 이 “필터” 검색 상자가 기본적으로 현재 카테고리 내에서 사용자 정의 검색 쿼리로 작동하도록 변경된다면(결과가 없을 때 이를 묻는 대신) 훨씬 더 효과적일 것 같습니다. 제목이 매우 짧기 때문에, 해당 분야에 익숙하지 않은 사용자가 입력하는 내용과 일치하는 결과가 나오는 경우는 대부분 없을 것입니다.