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 Like
Thank you! It works!
1 Like
Feature request: please add the ability to show an excerpt of the topic
Is it possible the Tag-Feature is bugged or behaving unexpectedly, when working with a restricted Tag Group?
I created a Tag Group with the following restriction:
Tags are visible to everyone, but only the following groups can use them
→ Admins, Moderators
I added the ‘featured’ Tag from this component to this Group.
Those are my component settings:
When I create a topic as an Admin with the featured Tag, the tag is visible to me and to moderators, but not to other Usergroups. For other registered Users it just shows exactly like this:
Tag1, Tag2,
To Admins and Mods, the featured Tag will show up correctly:
Tag1, Tag2, featured
Another thing: if it’s hidden, I think the comma should not show. This confuses users.
Also, I’m not sure if this is relevant, but the threads are in categories that are only visible to registered Users, not to Guests.
Ah, and by the way: Thanks for the component, awesome work! Other than that tiny feature, it works perfectly for me!
Ha, I found my own old topic when I was searching for a little annoyance 
So I just realised (again) that the actual images that are loaded are huge compared to their actual rendered size. In my case, it’s loading 1000x1000px image and rendering them at < 200px.
I checked some of the data, and if I could replace them with the 400x400px version, that would save around 83% in bandwidth (for the featured row), or 1.6MB total. I know these images are cached, but this will definitely make an impact on the initial page load and I suppose it also won’t help with speeding up page rendering? I’m using these featured images on every page on my forum, so I think the impact is real.
Would it be possible to add an option to the configuration of the TC to let us choose which image size to use, so everyone can tweak this to their own theme?
1 Like
Good catch! it’s been a while since I’ve looked at this component so I was able to do a general improvement pass:
https://github.com/discourse/discourse-homepage-feature-component/pull/96
This updates the images to use srcset, so the appropriate image for the container is used automatically. Available sizes can be set using a new `featured_image_sizes` setting.
I’ve also fixed the hide featured tag setting (wasn’t working so the tags were hidden always) and updated to the tags type setting rather than the plain text input. This also means that multiple tags may be used if desired.
1 Like
Nice, thank you! I think this also solves the issue with the missing featured tag that was really puzzling.
One thing though: since updating, this has kicked off a LOT of image processing jobs - I have over 20k queued up now. Is that expected? It seems rather wasteful as I only really need the last 5..
1 Like
Hmm yes good point, unfortunately there’s no way to avoid this. I think it’s probably worth reverting that piece because of it. I’m doing that here:
The reality is that I can’t produce a targeted subset of optimized thumbnail images from a theme this way, it has to be all or nothing. So we’ll need some other method of optimizing for more limited cases like this.
You can kill the sidekiq job from the rails console:
require "sidekiq/api"
Sidekiq::Queue.new("ultra_low").each do |job|
job.delete if job.klass == "Jobs::GenerateTopicThumbnails"
end
1 Like
Understood. Will the unneeded thumbnails be automatically removed later?
And it looks like my theme already has a bunch of different image formats that might work fine - like the 400x400 or 500x500. How about making those selectable? Compared to the currently used 1024x1024 that would already give a nice bandwidth saving, and no additional processing/storage overhead.
(ignore the 300x300, 600x600 and 900x900 ones that were added by the TC update):
-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 Like
I don’t think so, because the source images are still in use and these are optimized versions. No real harm other than eating up some storage.
You could clean those up from the rails console, this covers the sizes that were included by default for the setting, and won’t remove images that were generated from a modifier elsewhere.
# 1. See what actually exists vs. what's still legitimately registered
still_needed = Topic.thumbnail_sizes +
ThemeModifierHelper.new(theme_ids: Theme.pluck(:id)).topic_thumbnail_sizes
TopicThumbnail.group(:max_width, :max_height).count
# 2. Remove the unwanted sizes (files + records)
[[300, 300], [600, 600], [900, 900]].each do |w, h|
next if still_needed.include?([w, h]) # don't touch sizes something else still uses
TopicThumbnail
.where(max_width: w, max_height: h)
.find_each { |tt| tt.optimized_image&.destroy! }
# attempt-records with no optimized image don't cascade
TopicThumbnail.where(max_width: w, max_height: h).delete_all
end
oh yes, good idea — I can check to see what thumbnails exist already and if there are any, use the best size. If only the originals are available, that will always work as fallback.
Doing this here:
2 Likes
Brilliant, I’ll test that tonight!
And I was just returning here to re-list an old request of mine: would it be possible to add an option to sort the featured row by tagging date? Our order of featuring is not determined by the creation date of a topic OR by latest activity - for us it’s the moment we apply the tag that should determine the order. I didn’t realise before, but our featured row is a bit of a hot mess right now 
1 Like
Unfortunately I don’t think that’s possible… we don’t have a way to sort a topic list by when a tag was added. One way to workaround this would be to edit the timestamp of the topic?
1 Like
No worries. I’m working around this now with a bit of duct tape: I’ve forked your TC and created a Data Explorer query to fetch me the featured topics, sorted by tagging date and including the image urls. A small external web script loads and caches this data and returns the JSON to the TC. Works like a charm, even if it’s a bit ugly
Happy to share my code and query if anyone needs it.
2 Likes
Update: Okay, I realised this was actually only half of my issue. We also use the Topic Thumbnails theme component to display a gallery of the featured artworks. And the sort order of the gallery now didn’t match that of our featured row anymore, which confused visitors (and annoyed me). So the gallery had to be sorted by tagging date too - not just topic creation or last activity date.
And this is where I became a bad boy and turned to Claude Code to help me out. First, I had it create a small plugin to add an option to sort tag lists by tagging date, like /tag/featured?order=tag_date.
Once that worked, I updated the sorting option in the Homepage Feature TC by adding tag_date, replacing the clunky external JSON url I used before. I also changed the widget from checkboxes to a dropdown for a better UX:
Next I saw that the Topic Thumbnails theme component handles the new tagging order out of the box. By using /tag/featured/1?order=tag_date as the gallery URL I now have a featured row that acts the way I want it to (and, frankly, the way I believe it should ), AND a gallery that matches:
If anyone wants to try, here’s my code:
- discourse-sort-by-tagging-date plugin
- Homepage Feature component with support for the new tag_date option
You can see it in action on https://blenderartists.org/
Fair warning: this is all Claude Code work. I reviewed what I could but ultimately I’m not an expert at this. BlenderArtists is a faily high traffic forum though, so I watched the performance impact carefully. I will keep these updated as needed as they’re a key part of our 3D graphics community.
Enjoy!