CSSでできるかもしれません。
最後のメッセージの前に、以下を試しました。これにより、特集フォントサイズの問題は解決しましたが、ホームページのトピックリストの残りのフォントサイズが非常に小さくなってしまいました。
.featured-topic {
font-size: 9px;
}
これらのリンクについて言及されていますか？
これを変更しても、ページの他の部分に変更は見られません。
上記のCSSコードを適用した後、トピックリストは以下のようになります。フォントがかなり小さくなりました。
CSSコードを削除すると、トピックリストのフォントサイズは元に戻りました。
承知しました。こちらをお試しください。
.featured-topic h3 a {
font-size: 9px;
}
「いいね！」 1
ありがとうございます！動作しました！
「いいね！」 1
機能リクエスト：トピックの抜粋を表示する機能を追加してください
タグ機能は、制限されたタググループで作業する場合、バグがあるか予期せぬ動作をしている可能性がありますか？
以下の制限を設けてタググループを作成しました。
タグは全員に表示されますが、使用できるのは次のグループのみです
- 管理者、モデレーター
このコンポーネントの「featured」タグをこのグループに追加しました。
コンポーネントの設定は次のとおりです。
管理者として「featured」タグを付けてトピックを作成すると、タグは私とモデレーターには見えますが、他のユーザーグループには表示されません。他の登録ユーザーには、次のように表示されます。
Tag1, Tag2,
管理者とモデレーターには、「featured」タグが正しく表示されます。
Tag1, Tag2, featured
もう一つ：非表示になっている場合、カンマが表示されるべきではないと思います。これはユーザーを混乱させます。
また、関連があるかどうかわかりませんが、スレッドはゲストには表示されず、登録ユーザーにのみ表示されるカテゴリにあります。
ああ、それと、コンポーネントありがとうございます、素晴らしい出来栄えです！この小さな機能以外は、私にとっては完璧に機能しています！
ハッ、ちょっとした不満を調べているうちに、自分がかつて投稿した古いトピックを見つけちゃいました 
改めて気づいたのですが、実際に読み込まれている画像のサイズは、レンダリングされる実際のサイズと比べて非常に大きいです。私の場合、1000x1000px の画像を読み込んで、200px 未満のサイズで表示しています。
いくつかのデータをチェックしたところ、これらを 400x400px のバージョンに置き換えられれば、帯域幅を約 83%（フィーチャー行の場合）節約でき、合計で 1.6MB 削減できるようです。これらの画像はキャッシュされていることは承知していますが、これにより初期ページ読み込みに確実に影響が出るでしょうし、ページレンダリングの高速化にもならないと思われます。私のフォーラムの各ページでこれらのフィーチャー画像を使用しているので、その影響は現実的な問題だと考えています。
TC の設定にオプションを追加して、使用する画像サイズを選択できるようにすることは可能でしょうか？そうすれば、各自で自分のテーマに合わせて調整できるはずです。
「いいね！」 1
良い指摘ですね！このコンポーネントをチェックしてから少し経っていたので、一般的な改善を施すことができました：
https://github.com/discourse/discourse-homepage-feature-component/pull/96
これにより、画像が srcset を使用するように更新され、コンテナに適した画像が自動的に使用されます。利用可能なサイズは、新しい featured_image_sizes 設定で指定できます。
また、「featuredタグを非表示」設定も修正しました（以前は機能しておらず、タグが常に非表示になっていました）。さらに、プレーンテキスト入力ではなく、タグタイプ設定に更新しました。これにより、必要に応じて複数のタグを使用することも可能になります。
「いいね！」 1
素晴らしい、ありがとう！これで本当に謎だった、欠落している「featured」タグの問題も解決したと思います。
ただし一点だけ：アップデート以降、画像処理ジョブが大量に実行されています。現在、20,000件以上がキューに並んでいます。これは想定内の動作でしょうか？実際には最後の5件しか必要ないので、かなり無駄に思えます。
「いいね！」 1
うーん、その点も確かに。残念ながら、これを回避する方法はありません。そのため、その部分を元に戻す価値があると思います。こちらで行っています：
現実には、この方法ではテーマから最適化されたサムネイル画像のターゲットを絞ったサブセットを生成することはできません。すべてか無しかです。したがって、このようなより限定的なケースを最適化するための別の方法が必要になります。
「いいね！」 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 コンソールからそれらをクリーンアップすることができます。この処理は設定にデフォルトで含まれていたサイズを対象とし、他の場所で生成された修飾子からの画像は削除しません。
# 1. 実際に存在するもの vs 依然として正当に登録されているものを確認
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! }
# 最適化された画像がない試行レコードはカスケード削除されないため
TopicThumbnail.where(max_width: w, max_height: h).delete_all
end
ああ、いいアイデアですね。すでに存在するサムネイルを確認し、もしあれば最適なサイズを使用するようにします。オリジナルのみが利用可能な場合は、それが常にフォールバックとして機能します。
こちらで対応します：
「いいね！」 2
素晴らしい、今夜それをテストしてみます！
そして、ちょうどここで私の古いリクエストを再提示しようとしていました：特徴的な行をタグ付け日で並べ替えるオプションを追加することは可能でしょうか？ 私たちの特徴的な行の順序は、トピックの作成日や最新活動によって決まるものではありません。私達にとって、タグを適用した瞬間が順序を決定するべきです。以前は気づいていませんでしたが、現在の特徴的な行は少し混乱しています 
「いいね！」 1
残念ながら、それは不可能だと思われます… タグが追加された時刻でトピックリストを並べ替える方法はありません。これを回避する一つの方法は、トピックのタイムスタンプを編集することでしょうか？
「いいね！」 1
大丈夫です。今は少し強引な方法（ダクトテープ方式）で回避しています。あなたのTCをフォークし、Data Explorerのクエリを作成して、タグ付け日順に並べ替え、画像URLを含んだ注目トピックを取得しています。小さな外部Webスクリプトがこのデータを取得してキャッシュし、TCにJSONを返しています。少しダサいですが、完璧に動作しています
必要なら、コードとクエリを共有できます。
「いいね！」 2
更新: さて、これは実際には私の問題の半分だけだったことに気づきました。私たちはまた、注目されているアートワークのギャラリーを表示するために、ホームページ機能 TC を使用しています。そして、ギャラリーの並べ替え順序が、もはや私たちの注目行のものと一致しなくなり、訪問者（そして私）を混乱させました。そのため、ギャラリーもタグ付け日によって並べ替える必要がありました — トピックの作成日や最終活動日だけでなく。
そしてここで、私は悪少年になり、Claude Code に助けを借りることにしました。まず、タグ付け日によってタグリストを並べ替えるオプションを追加する小さなプラグインを作成させました。例えば、/tag/featured?order=tag_date のように。
それが動作したら、Homepage Feature TC の並べ替えオプションを拡張し、tag_date を追加しました。また、ウィジェットをチェックボックスからドロップダウンに変更しました：
そして見よ！今では、私が望むように（そして、正直に言うと、そうあるべき と信じるように ）動作する注目行と、それに一致するギャラリーを持っています：
試してみたい人がいる場合、ここに私のコードがあります：
https://blenderartists.org/ で実際に動作している様子を見ることができます。
警告：これはすべて Claude Code の仕事です。できる限りのレビューは行いましたが、最終的にはこの分野の専門家ではありません。私たちの 3D グラフィックスコミュニティの重要な部分であるため、必要に応じてこれらを更新していきます。
お楽しみください！
「いいね！」 1