You can probably do so with some CSS.
Before the last message, I tried the following. It fixed the issue with the feature font size, but it made the rest of the home page topic list font size super small.
.featured-topic {
font-size: 9px;
}
Are you referring to these links?
I don’t see any changes with the rest of the page if I change that.
You can see the topic list below after I applied the CSS code above. The font became quite small.
Removed the CSS code, and the font size in the topic list became normal again.
Right. Try this:
.featured-topic h3 a {
font-size: 9px;
}
1개의 좋아요
Thank you! It works!
1개의 좋아요
기능 요청: 주제 발췌를 표시할 수 있는 기능을 추가해 주세요
제한된 태그 그룹(Tag Group)을 사용할 때 태그 기능이 버그가 있거나 의도하지 않은 동작을 하는 것은 가능한가요?
다음과 같은 제한 사항을 가진 태그 그룹을 생성했습니다:
태그는 모든 사람에게 표시되지만, 다음 그룹만 사용할 수 있습니다
→ Admins, Moderators
이 컴포넌트에서 ‘featured’ 태그를 이 그룹에 추가했습니다.
제 컴포넌트 설정은 다음과 같습니다:
Admin으로 ‘featured’ 태그를 포함하여 주제를 생성하면, 저와 모더레이터에게는 태그가 표시되지만 다른 사용자 그룹에는 표시되지 않습니다. 다른 등록된 사용자에게는 정확히 다음과 같이 표시됩니다:
Tag1, Tag2,
Admin과 Mods에게는 ‘featured’ 태그가 올바르게 표시됩니다:
Tag1, Tag2, featured
또 다른 점: 태그가 숨겨진 경우 쉼표도 표시되지 않아야 한다고 생각합니다. 이것이 사용자를 혼란스럽게 합니다.
또한 이것이 관련 있는지는 확실하지 않지만, 해당 스레드는 게스트가 아닌 등록된 사용자만 볼 수 있는 카테고리 내에 있습니다.
아, 그리고 참고로: 컴포넌트를 만들어 주셔서 감사합니다. 정말 훌륭한 작업입니다! 그 작은 기능 문제를 제외하면 저에게는 완벽하게 작동합니다!
하, 작은 번거로움을 검색하다가 내 옛날 게시물을 발견했어요 
그래서 (다시 한번) 실제로 로드되는 이미지가 실제 렌더링 크기에 비해 엄청나게 크다는 걸 깨달았어요. 제 경우를 보면, 1000x1000px 이미지가 로드되는데 렌더링은 200px 미만으로 이루어지고 있거든요.
데이터를 몇 가지 확인해 보니, 400x400px 버전으로 교체할 수 있다면 대역폭을 약 83% (피처드 행 기준) 절감하거나 총 1.6MB를 절약할 수 있을 것 같아요. 이 이미지들이 캐시된다는 건 알지만, 초기 페이지 로딩에는 분명히 영향을 미칠 거라고 생각해요. 그리고 페이지 렌더링 속도 향상에도 도움이 안 될 것 같고요. 저는 포럼의 모든 페이지에서 이 피처드 이미지를 사용하고 있어서, 그 영향이 실재한다고 생각해요.
TC 설정에 옵션을 추가해서 사용할 이미지 크기를 선택할 수 있게 하면, 각자 자신의 테마에 맞게 조정할 수 있을까요?
1개의 좋아요
좋은 지적입니다! 이 컴포넌트를 살펴본 지 좀 오래 되어 전반적인 개선 작업을 진행할 수 있었습니다:
이것은 이미지들이 srcset을 사용하도록 업데이트하여, 컨테이너에 적합한 이미지가 자동으로 사용되도록 합니다. 사용 가능한 크기는 새로 추가된 featured_image_sizes 설정을 통해 설정할 수 있습니다.
또한 hide featured tag 설정도 수정했습니다(이전에는 작동하지 않아 태그가 항상 숨겨져 있었음) 그리고 일반 텍스트 입력 대신 태그 유형 설정으로 업데이트했습니다. 이는 원할 경우 여러 태그를 사용할 수 있음을 의미합니다.
1개의 좋아요
좋아요, 감사합니다! 정말로 당혹스러웠던 누락된 featured 태그 문제도 함께 해결된 것 같습니다.
한 가지, 업데이트 이후 이미지 처리 작업이 대량으로 시작되었는데, 현재 2만 개 이상이 대기 중입니다. 예상되는 현상인가요? 실제로는 마지막 5개만 필요하기 때문에 다소 낭비되는 것 같습니다.
1개의 좋아요
음, 좋은 지적이네요. 불행히도 이를 피할 방법이 없습니다. 이 때문에 해당 부분을 되돌리는 것이 옳다고 생각합니다. 여기서 처리하겠습니다:
현실적으로 이 방식으로 테마에서 최적화된 썸네일 이미지의 대상 부분 집합만 생성할 수 없으며, 전부 하거나 전혀 하지 않는(all or nothing) 방식이어야 합니다. 따라서 이 경우처럼 더 제한적인 시나리오에 최적화하기 위한 다른 방법이 필요합니다.
Rails 콘솔에서 Sidekiq 작업을 삭제할 수 있습니다:
require "sidekiq/api"
Sidekiq::Queue.new("ultra_low").each do |job|
job.delete if job.klass == "Jobs::GenerateTopicThumbnails"
end
1개의 좋아요
알겠습니다. 불필요한 썸네일들은 나중에 자동으로 삭제되나요?
그리고 제 테마에는 이미 400x400이나 500x500처럼 문제없이 작동할 수 있는 여러 이미지 형식이 있는 것 같습니다. 이들을 선택할 수 있게 하면 어떨까요? 현재 사용 중인 1024x1024와 비교하면 이미 상당한 대역폭 절감 효과를 얻을 수 있고, 추가적인 처리나 저장소 오버헤드도 없으니까요.
(TC 업데이트로 추가된 300x300, 600x600, 900x900은 무시해 주세요):
-rw-r--r-- 1 1000 www-data 723K Jun 23 21:32 80c77ac08d5671a1dc6d2a15ddea28e6d56f98c9_2_1000x1000.jpeg
-rw-r--r-- 1 1000 www-data 757K Jun 23 21:32 80c77ac08d5671a1dc6d2a15ddea28e6d56f98c9_2_1024x1024.jpeg
-rw-r--r-- 1 1000 www-data 30K Jun 23 21:32 80c77ac08d5671a1dc6d2a15ddea28e6d56f98c9_2_200x200.jpeg
-rw-r--r-- 1 1000 www-data 68K Jun 23 21:32 80c77ac08d5671a1dc6d2a15ddea28e6d56f98c9_2_300x300.jpeg
-rw-r--r-- 1 1000 www-data 118K Jun 23 21:32 80c77ac08d5671a1dc6d2a15ddea28e6d56f98c9_2_400x400.jpeg
-rw-r--r-- 1 1000 www-data 185K Jun 23 21:32 80c77ac08d5671a1dc6d2a15ddea28e6d56f98c9_2_500x500.jpeg
-rw-r--r-- 1 1000 www-data 263K Jun 23 21:32 80c77ac08d5671a1dc6d2a15ddea28e6d56f98c9_2_600x600.jpeg
-rw-r--r-- 1 1000 www-data 417K Jun 23 21:32 80c77ac08d5671a1dc6d2a15ddea28e6d56f98c9_2_750x750.jpeg
-rw-r--r-- 1 1000 www-data 470K Jun 23 21:32 80c77ac08d5671a1dc6d2a15ddea28e6d56f98c9_2_800x800.jpeg
-rw-r--r-- 1 1000 www-data 595K Jun 30 22:18 80c77ac08d5671a1dc6d2a15ddea28e6d56f98c9_2_900x900.jpeg
1개의 좋아요
아니라고 생각합니다. 원본 이미지는 여전히 사용 중이고, 이 이미지들은 최적화된 버전이므로요. 저장 공간을 조금 차지하는 것 외에는 실질적인 해로움이 없습니다.
Rails 콘솔을 통해 정리할 수 있습니다. 이 방법은 해당 설정에 기본적으로 포함된 크기를 처리하며, 다른 곳에서 수정자(modifier)를 통해 생성된 이미지들은 삭제하지 않습니다.
# 1. 실제로 존재하는 것과 여전히 정당하게 등록되어 있는 것 확인
still_needed = Topic.thumbnail_sizes +
ThemeModifierHelper.new(theme_ids: Theme.pluck(:id)).topic_thumbnail_sizes
TopicThumbnail.group(:max_width, :max_height).count
# 2. 원하지 않는 크기(파일 + 레코드) 제거
[[300, 300], [600, 600], [900, 900]].each do |w, h|
next if still_needed.include?([w, h]) # 다른 곳에서 여전히 사용하는 크기는 건드리지 않음
TopicThumbnail
.where(max_width: w, max_height: h)
.find_each { |tt| tt.optimized_image&.destroy! }
# 최적화된 이미지가 없는 시도(attempt) 레코드는 연쇄 삭제되지 않음
TopicThumbnail.where(max_width: w, max_height: h).delete_all
end
오, 좋은 아이디어입니다 — 이미 존재하는 섬네일이 있는지 확인하고, 있다면 가장 적절한 크기를 사용하겠습니다. 오리지널만 사용 가능한 경우, 그것은 항상 폴백으로 작동할 것입니다.
여기서 진행합니다:
2개의 좋아요
훌륭하네요, 오늘 밤에 테스트해 볼게요!
그리고 제가 여기서 오래된 요청을 다시 올리고자 돌아왔습니다: 추천 행을 태그 날짜 기준으로 정렬할 수 있는 옵션을 추가할 수 있을까요? 저희의 추천 순서는 주제 생성일이나 최신 활동으로 결정되지 않습니다. 저희에게는 태그를 적용한 시점이 순서를 결정해야 합니다. 이전에는 몰랐는데, 현재 저희의 추천 행은 좀 엉망이 되어 있네요 
1개의 좋아요
안타깝게도 그건 불가능한 것 같습니다… 태그가 추가된 시점에 따라 토픽 목록을 정렬할 방법이 없거든요. 이 문제를 우회하는 한 가지 방법은 토픽의 타임스탬프를 수정하는 것입니다?
1개의 좋아요
걱정 마세요. 지금 이 문제를 우회하는 방식으로 처리 중인데, 비닐 테이프(duct tape)로 살짝 붙여놓은 상태예요. TC를 포크해서 Data Explorer 쿼리를 만들어서, 이미지 URL을 포함하고 태그 날짜순으로 정렬된 추천 토픽을 가져오고 있습니다. 작은 외부 웹 스크립트가 이 데이터를 로드하고 캐시한 뒤, TC에 JSON으로 반환해줍니다. 조금은 투박하지만, 정말 잘 작동하고 있어요
혹시 필요하신 분이 있으면 제 코드와 쿼리를 공유할 수 있습니다.
2개의 좋아요
업데이트: 아, 이제 내 문제가 실제로는 절반에 불과했음을 깨달았습니다. 저희는 또한 Topic Thumbnails 테마 컴포넌트를 사용하여 추천 아트워크 갤러리를 표시하고 있습니다. 그런데 이제 갤러리의 정렬 순서가 추천 행(Featured row)의 순서와 맞지 않게 되어 방문자들을 혼란스럽게 했죠(그리고 저를 짜증나게 했고요). 따라서 갤러리도 태그 지정 날짜로 정렬되어야 했습니다 - 단순히 토픽 생성일이나 마지막 활동일만으로는 부족했으니까요.
그리고 바로 여기서 저는 '나쁜 아이’가 되어 Claude Code에게 도움을 청했습니다. 먼저, /tag/featured?order=tag_date처럼 태그 목록을 태그 지정 날짜로 정렬할 수 있는 옵션을 추가하는 작은 플러그인을 만들라고 했습니다.
그것이 작동하자, 저는 Homepage Feature TC의 정렬 옵션을 업데이트하여 tag_date를 추가하고, 이전에 사용했던 복잡한 외부 JSON URL을 대체했습니다. 또한 더 나은 UX를 위해 위젯을 체크박스에서 드롭다운으로 변경했습니다:
다음으로, Topic Thumbnails 테마 컴포넌트가 새로운 태그 지정 순서를 기본적으로 처리한다는 것을 알게 되었습니다. /tag/featured/1?order=tag_date를 갤러리 URL로 사용하면 이제 제가 원하는 방식(솔직히 말해서, 그렇게 되어야 한다고 믿는 방식 )으로 작동하는 추천 행과 그에 맞춰 정렬된 갤러리를 모두 가질 수 있게 되었습니다:
누군가 시도해 보고 싶다면, 제 코드는 다음과 같습니다:
https://blenderartists.org/에서 작동하는 모습을 볼 수 있습니다.
참고로: 이 모든 것은 Claude Code의 작업입니다. 제가 검토할 수 있는 부분은 검토했지만, 결국 이 분야에 전문가가 아닙니다. BlenderArtists는 상당히 높은 트래픽을 가진 포럼이므로, 성능 영향을 주의 깊게 지켜보았습니다. 이 코드는 저희 3D 그래픽 커뮤니티의 핵심 부분이기 때문에 필요에 따라 계속 업데이트할 예정입니다.
즐겁게 사용하세요!
1개의 좋아요