카테고리 1,000개 이상인 사이트의 하위 카테고리 보기 문제

기여 버그
1

카테고리가 1,000개 이상인 사이트를 호스팅하고 있습니다. 이 사이트의 커뮤니티는 태그보다 카테고리를 사용하여 의미를 구분하는 방식을 선호합니다.

현재까지는 비교적 잘 작동하고 있지만, 최근(정확히 언제부터인지 불분명하지만) 문제가 발생했습니다:

서브카테고리가 20개 이상인 카테고리 뷰를 방문할 때, 서브카테고리 링크 요소를 "Boxes"로 렌더링하는 경우 목록에 (첫 번째?) 20개 카테고리만 표시됩니다.
details 드롭다운 선택 요소에 클릭하면 전체 목록이 표시됩니다.

초기 조사 과정에서 discourse/app/models/category_list.rb at main · discourse/discourse · GitHub 파일과, 카테고리 1,000개 이상인 사이트를 처리하는 로직을 발견했습니다.

이 로직과 함께 discourse/app/views/categories/index.html.erb at main · discourse/discourse · GitHub 뷰가 수신한 카테고리 목록을 페이지네이션 없이 처리하는 방식이 결합되어, 뷰에 서브카테고리 20개만 표시되는 원인이 될 것이라고 추정합니다.

이것이 의도된 동작인가요?

2

네, 그 추측이 정확하다고 생각해요. Discourse는 여러 가지 이유로 수천 개의 카테고리를 처리하도록 설계되지 않았습니다. 카테고리 로딩에 대한 작업을 진행 중이라, 미래에는 상황이 달라질 수도 있습니다.

3개의 좋아요
3

설명해 주셔서 감사합니다.

CategoryList::CATEGORIES_PER_PAGE 또는 CategoryList::MAX_UNOPTIMIZED_CATEGORIES를 어떤 방식으로든 설정할 수 있도록 해 주실 수 있을까요? 내 경우에는 숨겨진 사이트 설정만 있어도 충분합니다.

이 값을 대체하기 위해 플러그인 코드를 작성하는 것은 다소 지저분한데, CategoryList를 몽키 패칭하는 것 외에는 다른 방법을 찾지 못했기 때문입니다. 몽키 패칭은 매우 불안정하게 느껴집니다.

4

몽키 패칭(monkey patching)의 세계로 들어가는 것은 분명 이상적이지 않습니다.

그럼에도 불구하고 CategoryList::MAX_UNOPTIMIZED_CATEGORIES를 건드리는 것에 대해서는 우려가 있습니다. 수치가 높아지면 문제가 발생하기 때문에 이 값을 선택했습니다. 하지만 CategoryList::CATEGORIES_PER_PAGE는 100까지 비교적 무리 없이 올릴 수 있을 것 같습니다.

@nbianca / @hugh 이 부분에 대해 의견이 있으신가요?

3개의 좋아요
6

이것은 방금 수정한 버그입니다:

https://github.com/discourse/discourse/pull/31507

카테고리가 1,000개 이상인 사이트에서 “/categories” 페이지가 사용 불가능했던 문제를 해결하기 위해 이 기능을 도입했습니다. 불행히도, 이로 인해 버그가 발생했는데, 사이트의 카테고리가 1,000개를 초과하면 하위 카테고리도 지연 로딩(또는 페이지별 로딩)을 강제하려고 시도합니다. 이는 실제로 필요하지 않은 경우에도 마찬가지입니다.

4개의 좋아요