아, 확실히 버그네요. 조사해봐야겠어요. 잘 찾아주셨네요!
훌륭합니다. PR 감사합니다. 병합 완료했습니다!:
![]()
세 가지 과제:
- 섬네일(썸네일)이 여기서 직렬화되지 않는다고 확신합니다. 확인해 주셔도 좋습니다. 이는 사이드카 플러그인을 강화함으로써 해결할 수 있습니다.
- 마지막으로 이 부분을 살펴봤을 때, 페이지 구조가 리프 템플릿에 한정된 저위험 오버라이드를 허용하지 않았습니다. 일반적으로 전체 페이지를 오버라이드하는 것은 깨지는 변경 사항(breaking changes)을 일으키거나 코어 기능 업데이트를 가릴 수 있으므로 원하지 않습니다. 여기서는 코어에 대한 PR이 도움이 될 수 있습니다 …
- 공간?
필요한 PR을 제출해 주세요
좋은 지적입니다. 카테고리 페이지에는 박스형이나 유사한 다른 프레젠테이션 방식을 선택할 수도 있겠네요.
또 다른 질문이 있습니다.
카테고리 페이지(토픽 목록을 포함하는 페이지)를 모바일에서는 타일 형태로, 데스크톱에서는 섬네일(썸네일)이 포함된 형태로 표시할 수 있을까요? 여러 설정을 시도해 보았지만 원하는 결과를 얻지 못했습니다.
수정: 해결했습니다. 혹시 다른 분들에게 도움이 될 수 있을지 모르겠지만, 나중에 어떻게 해결했는지 자세히 설명할 것입니다. 이 수정을 추가한 이유는 다른 분들이 저에게 어떻게 해야 하는지 설명하는 데 시간을 낭비하지 않도록 하기 위해서입니다 ![]()
제가 잘못 알고 있다면 지적해 주십시오. 설정은 다음과 같습니다…
우선, (최소한) 토픽 목록의 모바일 보기에서만 타일 디스플레이가 필요합니다:
그리고 데스크톱과 모바일 모두에 대한 섬네일(썸네일) 설정입니다:
처음에는 "타일"과 "섬네일(썸네일)"이 이미지가 포함된 토픽 목록의 두 가지 다른 프레젠테이션 방식이라고 생각해서 혼란스러웠습니다. 하지만 실제로는 그렇지 않습니다. 토픽 목록에 이미지가 표시되도록 하려면 타일 방식이든 아니든 섬네일(썸네일)이 필요합니다.
여기에 카테고리를 수동으로 추가할 필요는 없습니다:

다음 설정을 활성화하여 해당 설정을 오버라이드할 것이기 때문입니다:

이제 데스크톱에서는 최신 토픽, 특정 카테고리 등 모든 토픽 목록에서 작은 섬네일(썸네일)이, 모바일에서는 큰 섬네일(썸네일)이 포함된 “타일” 프레젠테이션이 표시되어야 합니다:
사용자 프로필에서 작은 문제가 발생했는데, 아마도 작은 버그인 것 같습니다:
썸네일에 대한 언급이 있으므로, 이 테마 컴포넌트와 관련이 있을 것으로 추정됩니다.
참고로, 이 테마 컴포넌트를 계속 테스트하고 있는데… 정말 훌륭합니다.
질문이 있습니다. 토픽에 실제로 썸네일 이미지가 포함되어 있더라도, 해당 토픽의 썸네일 표시를 방지하는 것이 가능한가요?
제 상황은 다음과 같습니다:
문서화(Docmentation) 카테고리가 있는데, 이 곳에서는 썸네일이 환영됩니다.
하지만 새 토픽을 생성할 때 일반적인 조언을 주는 토픽도 하나 있습니다:
이 토픽에는 의미 있는 이미지가 없는데도 썸네일이 자동으로 추가됩니다:
이 문제를 우회하는 유일한 방법은 토픽의 어딘가에 무작위 이미지를 추가하고 이를 썸네일로 설정하는 것 같습니다.
예시:
(하지만 솔직히 꽤 예쁘게 보이긴 합니다…)
아 네, 해당 로컬라이제이션이 실패하고 있으니 수정이 필요합니다. ![]()
아니면, 이미지가 있으면 하나를 사용하려고 합니다. 추가적으로 좋은 이미지를 하나 더 넣는 것이 완벽한 우회책입니다. ![]()
이렇게 하면 페이지 레이아웃의 일관성 측면에서도 더 좋아 보입니다.
어쨌든 저는 이러한 유형의 게시글을 상단에 요약하기 위해 추천 주제 컴포넌트(내장 TLP 또는 기타)를 자주 사용하는데, 이때 이미지가 있으면 꽤 좋습니다.
특정 카테고리 외에도 특정 태그에 대해 썸네일과 타일을 제한하려고 하고 있지만, 태그에는 작동하지 않습니다. 여기는 제 설정 페이지입니다. 저는 ‘featured’ 태그에 대해서만 타일과 썸네일이 표시되기를 원합니다. 제가 잘못하고 있는 부분이 있는지 알려 주실 수 있을까요?
플러그인 설정에서 누락된 문자열도 있습니다:

그리고 토픽 목록 발췌에서 링크 제거 옵션과 관련된 또 다른 버그가 있습니다.
즉, 이전에 보고된 바와 같이 이 옵션을 비활성화하면 링크는 물론이고 텍스트 자체와 “더 보기” 버튼조차 더 이상 표시되지 않습니다:
활성화하면 발췌문에 링크와 “더 보기” 링크가 표시되지만, 왜 그런지는 모르겠지만,
-
“더 보기” 링크가 링크로 스타일이 적용되지 않습니다(이것도 이미 보고된 내용이지만, 모두 동일한 옵션과 관련되어 있어 모든 문제를 한 번에 정리하는 것이 좋다고 생각합니다)
-
일부 발췌문이 잘못 줄바꿈됩니다. 몇 가지 예시:
여기서는 발췌문의 문장 중 첫 부분만 줄바꿈됩니다:
빈 줄이 발췌문으로 줄바꿈됩니다:
더 도움을 주고 싶지만, unfortunately 플러그인과 Discourse 코드의 대부분에 대해 아는 것이 없어서… ![]()
버그인 것 같네요. 곧 확인해볼게요.
beta 브랜치에서 이 문제를 수정했습니다. 이제 문제가 해결되었는지 확인해 주시겠습니까? 확인 후 머지하겠습니다.
이것이 작동하려면 tag와 tag-mobile을 제거하고 태그 목록 설정에 해당 태그를 추가해야 합니다.
(베타 버전을 다른 컴포넌트로 설치하고 테스트 테마와 연결하세요.)
코어에서 발생하는 깨지는 변경 사항(breaking change)이었음이 밝혀졌습니다.
고급 버튼(advanced button)을 사용하여 브랜치를 표시하고 beta를 입력하세요:
조금 지나도 연락이 없으면 아무튼 머지하겠지만, 테스트하고 피드백을 줄 수 있는 기회입니다.
이것은
를 통해 직접 해보면서, 조금씩 지식을 쌓아가는 과정에서만 얻을 수 있습니다
![]()
테마 컴포넌트가 설치된 경우 웹사이트 내비게이션 시에도 JS 오류가 발생합니다.
귀하의 웹사이트에서도 확인하실 수 있습니다: https://starzen.space/
아무 게시물이나 클릭한 후 JS 콘솔을 확인해 보세요.
TypeError: Cannot read properties of null (reading 'querySelector')
이 오류는 이 Discourse 파일의 해당 라인에서 발생하며:
코어에서 발생한 breaking change인 것 같습니다: FIX: Don't listen for focus/blur events if the topic-list opts out of… · discourse/discourse@97e7bb1 · GitHub
주로 이 커밋으로 수정되었습니다: COMPATIBILITY: add css class to tiles to support focus · merefield/discourse-tc-topic-list-previews@4f0f0f0 · GitHub
beta 브랜치에서 수정했으며, 제 사이트에서 데모로 확인했습니다.
이 방식의 장점은 이제 타일에서 마지막 방문 지시기가 표시된다는 점입니다 ![]()
(모바일에서도 대부분의 오류가 사라지지만, 이 지시기는 모바일에서는 일반적으로 표시되지 않으므로 수정 완료로 하겠습니다!)
제목 요소와 관련된 덜 빈번한 오류에 대해서는 추후 후속 조치가 필요합니다.
beta에서 수정되었습니다: FIX: missing localisation on user prefs and update locale paths
감사합니다!
topic list excerpt remove links 플러그인 옵션에 대해, 현재 사용 중인 정규식을 변경하는 것을 제안해도 될까요?
URI::regexp는 링크 패턴을 가진 모든 문자열을 제거하므로, 제 생각에는 항상 바람직한 방법은 아닙니다.
링크의 텍스트 내용이 href 값과 동일한 경우가 있습니다. 이는 포럼에서 매우 흔한 경우이며, 텍스트 내용을 제거하면 문장이 의미를 잃는 이상한 발췌문이 만들어질 수 있습니다.
이 정규식은 때때로 링크 내부 또는 외부에 있는 단어도 제거합니다. 아래에 예시를 제공합니다.
다른 정규식과의 비교입니다: <a .+?\>(.+)?<\/a>
이것은 단지 예시 정규식일 뿐이며, URI::regexp가 링크를 더 복잡하고(그리고 supposedly 더 신뢰할 수 있는) 방식으로 처리한다는 점은 이해하고 있습니다.
예시 게시물입니다:
그리고 주제 목록에서 생성된 발췌문입니다:
URI::regexp
↓
(페이스북 링크의 텍스트 내용이 제거되었고, "Astronomy Picture of the Day"에서 "Day"라는 단어가 이유 없이 제거되었습니다
<a .+?\>(.+)?<\/a>
↓
또 다른 예시입니다. 읽기 이상하게 만드는 링크 텍스트 내용만 제거된 경우입니다:
URI::regexp
↓
("링크는 ‘This may be my favorite halo’ 였는데…?"라는 의미)
<a .+?\>(.+)?<\/a>
↓
(이제 의미가 있습니다)
따라서, <a .+?\>(.+)?<\/a>가 더 낫다고 제안하는 것은 아니며, 이는 단순한 빠른 테스트였을 뿐입니다. 하지만 결과물에 관해 URI::regexp를 사용하는 것이 최선의 선택인지 확신이 서지 않습니다. 제가 언급한 두 가지 이유 때문입니다: 링크 텍스트 내용이 사라져서 발췌문이 때때로 이상해지고, 또한 링크 내부 또는 외부의 단어가 때때로 모호한 이유로 제거되기 때문입니다. 후자의 문제는 무시할 수 없을 정도로 자주 발생하는 것으로 보입니다.
현재 방식의 단점(예를 들어, 현재 알고리즘이 의외로 지나치게 열정적으로 동작하여 너무 많은 내용을 삭제하는 문제 포함)을 이해하고 있습니다. 하지만 우리는 경험을 통해 이 지점에 도달했습니다.
이 옵션이 존재하는 주된 이유는 실제로 다음과 같습니다:
- 링크가 매우 긴 경우 미리보기의 포맷을 유지하기 위함입니다(즉, 모든 링크를 삭제하여 긴 링크가 발췌문에 새어나와 문제를 일으키는 일이 없도록 합니다). 링크가 매우 매우 긴 시나리오를 시도해 보세요. 오래된 지원 토픽에는 긴 링크가 포함된 토픽 게시물로 인해 발생한 문제들로 가득 차 있습니다.
- 발췌문이 항상 해당 토픽으로 이동하는 예측 가능한 클릭 영역으로 유지되도록 하기 위함입니다. 텍스트가 너무 작아 이를 사용자의 재량에 맡길 수는 없습니다.
또한 다음과 같아야 합니다:
- 유지보수가 간단하고 지원 문의(노이즈)를 유발하지 않아야 합니다. 현재 방식은 지원되는 유틸리티 클래스이므로, 유지보수에 대해 걱정할 필요가 없습니다.
일반 대중을 위해 이 방식을 변경해야 할 필요가 있다고 아직 확신하지 못합니다.
이것을 세 가지 옵션(OFF, 링크 없음(즉, 현재 방식), 실험적)으로 선택 가능하게 만드는 데는 열려 있을 수 있습니다. PR 환영합니다. 먼저 현재 사이드카 코드를 마스터 플러그인 브랜치로 이동하겠습니다. 이번 주에 해보겠습니다.
답변 주셔서 감사합니다 ![]()
이전 게시글의 마지막 문장을 수정했습니다. 한 단어를 빠뜨렸거든요…
제가 쓴 문장은 다음과 같습니다.
그리고 때로는 모호한 이유로 링크 안팎의 단어를 삭제하기도 합니다. 후자의 문제는 충분히 흔해서 무시할 수 있는 정도입니다."
"not"을 빠뜨렸으니…
그리고 때로는 모호한 이유로 링크 안팎의 단어를 삭제하기도 합니다. 후자의 문제는 충분히 흔해서 무시할 수 없는 수준입니다.
코드 관련해서는 잘 이해하지 못하지만, 오늘 여기서 언급한 2번 문제를 이해하고 수정해 보겠습니다: Topic List Previews (TLP) - #110 by Canapin
(발췌문이 .topic-excerpt로 제대로 감싸지지 않고 있습니다: 래퍼가 발췌문 끝에 닫히는 대신, 발췌문에 포함된 첫 번째 링크 바로 전에 닫히는 것 같습니다)
솔직히 가장 좋은 방법은 해당 유틸리티의 유지보수자에게 이슈를 올려서 수정을 요청하는 것일지도 몰라요. 분명히 기대했던 대로 동작하지 않잖아요?
네, 아직 그 부분은 확인해 보지 못했어요. 그 사이에 수정을 위한 PR을 올려도 좋습니다.
감사합니다. 그 생각을 못 했네요. 이 유틸리티가 어디서 온 건지 전혀 몰랐거든요.
조금 검색해 본 결과, 기본적으로 정규 표현식이 콜론(
바로 뒤에 붙어 있는 경우(즉, 중간에 공백이 없는 경우) 거의 모든 단어나 문자열을 URI 스킴의 일부로 인식하는 것 같습니다. 이것은 이해할 수 있는 부분이지만, 영어의 경우(예를 들어 프랑스어와 달리) 단어와 콜론 사이에 공백을 넣지 않기 때문에 다소 과도한 면이 있습니다. 그래서 불행히도 콜론 뒤에 오는 합법적인 단어들이 정규 표현식에 의해 제거되는 문제가 발생하고 있습니다.
수정 방법으로는 플러그인 설정에 스킴을 입력할 수 있는 필드를 추가하는 것이 있을 수 있습니다(기존 설치 환경에 해를 끼치지 않도록 기본값을 비워둠).
예를 들어, 설정은 다음과 같을 수 있습니다:
제거할 URI 스킴: http|https|ftp|mailto
이 경우 결과는 다음과 같습니다:
#{URI::regexp(['http', 'https', 'ftp', 'mailto'])}
(불행히도 대소문자를 구분하지만, 어떤 방식으로든 조정할 수 있을 것입니다)
설정이 비어 있는 경우, 현재 동작과 동일하게 다음이 사용됩니다:
#{URI::regexp}
이러한 설정을 포함하는 풀 리퀘스트를 환영하시겠습니까?























