Topic List Previews

I have updated to latest version of the plugin (4.3.1) and discourse (2.5.0.beta4) and noticed that almost all of my topic list previews are gone :frowning:

I am able to regenerate the preview image on a per-topic basis, however this is a) time-consuming, and b) nudges the topics to the top after I update them.

Is there a way to automatically regenerate the topic thumbnails?

I really love this plugin - it’s done wonders for our forum and makes it look great. I also tried the [edit - it was a from a different author so not relevant to this discussion] TC but found it looks quite different and has less options - so this plugin still seems superior to me unless someone can correct me?

1 Like

Yep, a post rebake from the console will do it: Rebake all posts?

But before you do that make sure this is big:

Otherwise those posts won’t have their remote images brought into the forum and the thumbnails won’t then be created.

The Theme Component is work in progress and you need the ‘plugin sidecar’ installed for the complete feature set. Actions is not yet supported but will be soon when I get a moment.

Oh, how so? There is a slight approximation made on tile size, but apart from missing actions it should be identical (aside from the tiles ships with slight drop shadows on the TC which I prefer personally).


This worked perfectly, my thumbnails are rebuilt — thanks so much for the pointer!


Hey, similar issue as Ian C ; since the upgrade to Discourse 2.5.0.beta4, with Topic List Previews 4.4.0, most of the thumbnails disappeared (on a side-node, why not all?)



I’ve tried to rebake all posts. It did not help.

Any solution, please?

1 Like

Max days old is way too low. As I pointed out it should be a high number. 30 means anything older than a month will not be thumbnailed.

1 Like

The option is not enabled. It should not be affected, right?

You haven’t checked the box. Images have to be uploaded.

1 Like

It has been disabled because of various issues with it. Also conflicting with custom modifications if I remember.

So, It’s enabled, and I’ve increased max old days. What to do next? I’m not sure how this options works. Does it means we need to wait every single image is downloaded before re-trying again rebacking?

1 Like

This is mostly core discourse behaviour now, not TLP (It used to be all TLP, now there are minimal overrides in the plugin around this because Thumbnail support is now in core).

You need to rebake posts again and this will set up a load of UploadHotLinkImages sidekiq jobs and pull them all in. Within minutes it will start to populate the thumbnails.


Alright. It’s running. Thanks for the help!


How do I get the image thumbnails to appear when you are viewing topics in a category?


1 Like

Rebaking is done. What a messy result! :pensive:

Well, now I know why this option was disabled.

We are using Wordpress and the first post contains full html. Discourse has no issue to replace image HTML with markdown, but markdown image can’t be rendered if surrounded with HTML (or specifically you need a least en empty line above).

I have 2 problems:

  1. Some images were not downloaded, likely because of srcset attribute (but it’s okay). The images are well displayed in the first post, but there is no thumbnail generated. It was working before.

    Is there some breaking change in the plugin where thumbnail can’t be generated with post containing already image HTML? I believe I’ve rebaked 3 times now, it did not help. Is there another to force regenerate the thumbnail? I mean, before, even with the option disabled, a thumbnail was generated with any image on topic creation or even after editing it ; this behavior doesn’t work anymore.

  2. As said above, some markdown image are not rendered.

    I tried to see if some plugin API was available before post is cooked, but could not find one.

    I guess the only way is to add newlines in the concerned raw message directly in the DB and through the rails console, and rebacking again.

    Currently, I’m struggling (don’t know ruby) somehow based on discourse code source:
    It seems to work for one topic. Did not yet execute for all topics. Is there a better/cleaner way to fix the issue without doing that?

  .where(post_number: 1)
  .where("raw LIKE '%upload://%'").each do |post|  
     post.raw.gsub!(/(!\[.*upload:\/\/.*\))/, "\n\n\\1")!(validate: false); 

Any help is appreciated, thanks!

1 Like

Same problem here.

After rebaking the previews now work.

But each time I have to upgrade (not under my control, each time I made a rebuild for changing something the forum is upgraded) I cross my fingers.

1 Like

Christian, if you are referring to the Plugin, they are in the Category’s own Settings (not the main admin settings).

Have added a note to the OP to make that more clear! :slight_smile:

1 Like

Criteria for thumbnail building is largely deferred to Discourse core now.

Your issue is likely to occur with any add-in component that uses Discourse thumbnails. Should they broaden their criteria?

Could you post the complete raw contents of a problem post? If I ever get time (I can’t promise anything) I’ll see if it’s trivial to broaden inclusion. However, I’m a little reluctant to override this as Discourse having implemented this in core is a good reason to avoid overrides and rely more on core. This will help stability of the plugin and reduce breaking changes. It’s exactly this kind of customisation that trips up plugins.

You could always maintain your own fork and customise this yourself?

You could try to use the thumbnail picker in the Topic Meta editor to see if you can pick the thumbnail, but that is based on the same criteria for inclusion. If the thumbnail doesn’t appear there, it is not meeting the criteria, so that would act as a good confirmation.

1 Like

This is a pretty suboptimal arrangement.

If you want to optimise stability test upgrades in a staging environment, report/resolve any issues, then update production.

Applying untested changes directly to Production is usually a bad idea.

We do our best to deliver compatibility, focusing on the first 5 days of the month, but we are a change taker, with no warning, so update Discourse the rest of the month at your own risk. And please test your upgrades in a safe environment!


EDIT: comment moved to Problems with thumbnails from Soundcloud and YouTube oneboxes.


Yeah, as above, most thumbnailing logic is now in Discourse. I actually override to loosen the inclusion requirement slightly, but it still may be stricter than before.

I’m wary of overriding any more and really the ‘looseness’ of the criteria for considering something worthy of thumbnailing should now be a core issue. TLP should really just be a customer of that data.

OK now picked up here: Problems with thumbnails from Soundcloud and YouTube oneboxes


Well, the initial issue is likely because of FEATURE: Include optimized thumbnails for topics (#9215) · discourse/discourse@03818e6 · GitHub where it seems thumbnail can be only uploads now. Discourse always first in breaking behavior/changes. Sorry for being salty, it’s just frustrating. :pensive:

I get it it now depends on Discourse behavior. Thanks for the help.

Just telling my status on this. Still struggling.

I’ve tried to normalize img html to include only src attribute since it seems to be ignored by discourse. For example usually a post from WP would start to contain this (here I’ve already cleaned the html, no attributes except src). The criteria you’re talking about does not seems to be related.

<div data-wp><a href="" target="_blank"><img src="" /></a><div><div data-buy>

Then rebaking (so image are downloaded) from the console would work only for some topics.
Typically the topic where I’ve extracted the HTML above is ignored. Whatever rake posts:rebake or in rails! ; post.rebake! ; the topic is ignored. I can’t see a reason why it fails, it has the same html as the others topics which worked.

However, if I edit manually from composer without changing the content and saving, then the image is extracted/downloaded. There are too much topics to edit manually.

Do you have an idea how you could achieve the same saving as composer does with rails console?

Note: the max old days option is set to the maximum value

1 Like

That’s a very interesting, if frustrating, difference in behaviour. Can I suggest you post that as a Support Topic as that’s not really in scope of the plugin?

1 Like