I’ve attempted to set this up here, but thumbnails don’t seem to actually be generating for our topics.
Is this in any way tied to the editing grace period setting? The Topic List Previews theme component doesn’t get thumbnails until the first post is no longer editable, either — but this category does not suit that approach at all, and we’d prefer that users are able to edit their posts indefinitely in this category.
As front end mods only, Topic List Thumbnails & Topic List Previews leverage the same core process that generates thumbnails in the back end. That async job is not run until the editing grace period is over UPDATE: if the image is remote. If the images are uploaded locally the thumbnail generation process is kicked off straightaway.
The process is not modifiable by a Theme Component and would require a plugin or PR to the back end to change (not withstanding that TLP has a complementary plugin for some added features)
Note before thumbnail support was added to core, Topic List Previews was a plugin and worked in much the same way in terms of scheduling the creation of thumbnails. I can’t speak for the team but you can understand the logic of keeping it that way: you don’t want to be generating thumbnails whose source image might be frequently edited out or what if an image is added at last minute?
One way you can mitigate it is use the default icon/image feature in each theme component respectively. For masonry/tiles view this at least reduces dramatic changes in layout. Or minimise the grace period?
Ah, yeah, I see. It makes total sense for that to be the default behaviour — we’re in a tricky spot here because much of what will be posted in this category will be Minecraft mods, so it stands to reason that the first post in any topic will need to be edited infrequently, and the thumbnail is likely to be changed.
I assume you’re not aware of any plugins that allow you to change this behaviour, off the top of your head? I can see why Core doesn’t support this, but relying on the grace period just isn’t going to work for us.
Just to add though, a significant part of the battle is actually specifying the exact practical behaviour you want that will work in all edge cases. Then follow up with the work, ie make sure what you want will work in practice. It’s all modifiable. :).
If the post changes past the deadline I believe the system should schedule a another pull and update the thumbnail.
I think I may have been getting confused between the grace period and editing lockout, because as of a short while ago, thumbnails have just kinda started generating.
I think maybe I need to attribute that to a CDN caching mistake, haha. Still, thanks for your help!
Gareth, apologies for confusion, but now I’m back at my desk, I’ve done some quick testing and review of the logic.
My statement was incomplete:
If the image is remote in any way (including onebox of remote link, when it is held in a CDN?) the thumbnails are impacted by a delayed job: Jobs::PullHotlinkedImages and this is indeed scheduled after the editing grace period (this part was correct):
BUT: it appears if you upload an image directly to the site (e.g. by pasting an image), the thumbnails are created in an async process which appears to be kicked off immediately. If you update the image to another local image, this will also be reflected almost immediately. I’ve updated a couple of Posts above. Because I don’t do this very often, I’d omitted this part.