Why does the API often fail to create thumbnails although big enough images are downloaded?
Example, if you paste this in an opening post…
This onebox downloads a large enough image with dimensions of 690 x 465:
Still, no thumbnail created for the topic.
It’s not based on the size of the image. In general, we do not take the images from oneboxes, because in a lot of cases they are not useful for thumbnails. For example, something we see a lot on Meta is GitHub repo links like
Nobody wants my face to be magnified and turned into the topic thumbnail 
Well, that is very specific for Meta, we don’t have any Github links in our community. It’s all about news and onebox images should be used. This is limiting the thumbnails very much, just because of this “face” issue on Meta. Is there a potential way to alter this and add images from oneboxes? I guess, many communities don’t care about Github “faces”.
I am certainly open to improvements here. I know @merefield is also interested in this logic. The change would be needed in core, rather than a plugin, so I’ll split this out into its own topic.
Here is the existing logic:
Maybe we could add a .no-thumbnail class to certain kinds of onebox (e.g. GitHub), and then teach Discourse to only ignore those, while keeping other onebox images.
Going to put pr-welcome on this, but be sure to lay out a plan in this topic before doing any substantial work.
That would be great. 90% of our topics currently don’t get thumbnails although they could. And as said, this Github issue is a very specific border-case for developer communities, the vast rest of us don’t get thumbnails for topics that certainly could have thumbnails, because of this.
I second this!!! For the use-case of a news aggregator or any other sort of repost-heavy page, not having relevant thumbnails is bad news.
If you guys don’t integrate this soon, are there any ideas on how to do this on my self-hosted distro?
Yes, it’s currently not on the table due to “faces” from Github could be rendered in developer communities like Meta, but the majority of communities out there don’t care about “faces” and want to have as many as possible thumbnails, in particular when large enough onebox images are available for the OP.
That OP example renders fine for Topic List Previews, because I use broader criteria in the plugin:
def extract_images_for_post
# all images with a src attribute
@doc.css("img[src]") -
# minus emojis
@doc.css("img.emoji") -
# minus images inside quotes
@doc.css(".quote img") -
# minus onebox site icons
@doc.css("img.site-icon") -
# minus onebox avatars
@doc.css("img.onebox-avatar") #Broader criteria than Discourse Core
end
Yes, thanks @merefield, but we just use @david’s theme component, not the TLP TC. But I will probably use your eval to patch core if we don’t get some movement or an option provided by the @team on this issue.
The above render is from the TLP TC, but yes, I use a back-end plugin (the theme ‘side car’) to modify the Ruby :).GitHub - merefield/discourse-topic-previews at theme_sidecar I appreciate that may not be an option if hosted.
This is totally on the table, that’s why it is tagged #pr-welcome 
Check this post for a starting point for implementation.
@merefield Kindly can you do the PR? Unfortunately, I am completely new to Ruby. Or how is the process for a PR?
@david I would definitely be delighted to be able to remove this override from the plugins and agree a core solution would be best.
@Terrapop here are the Discourse Development Contribution Guidelines
I would be a more immediate assistant on this but rammed with client work atm.
Understood. I just have a simple docker dev environment for developing some simple plugins and core patches, yet. Will wait until we have someone to look at this and probably patch via your eval in the meantime.
A proper job here is not an immaterial project, because you need to modify test cases, and work across the two components (discourse and discourse one-box). But definitely worth doing!
Ruby is nothing to fear after Ember btw
Yes, but this is defo out of my current scope and abilities unfortunately.
As a work around I often manually copy and paste the image into a whisper, then select the thumbnail from that.
Automatic would be nicer, perhaps with a config item to give domains where thumbnails shouldn’t be taken from one boxes (i.e. to cover the github case).
Agreed. We used @merefield snipped to override core with a mini plugin. But it should be easy for the core team to come up with something out of the box. Not having this just because some are afraid of having their Github faces showing up is just lazy.
I just merged FEATURE: Allow onebox images to be used as topic thumbnails (#12050) · discourse/discourse@b770c30 · GitHub which allows onebox images to be selected as topic thumbnails. There is a specific exception for the GitHub onebox, and we can add more as needed.
(cc @Terrapop @merefield)