As themes become more ambitious, we’ve been looking for ways to allow them to manipulate core server-side behaviour. While they will never be given the same level as control as plugins, we can provide some predefined hooks for themes to manipulate.
Introducing: theme modifiers
They are specified using the modifiers key in your theme’s about.json file.
For a 100% up-to-date list of modifiers, check the database schema at the bottom of theme_modifier_set.rb, but here’s a quick summary of what we have so far:
serialize_topic_excerptsboolean (default false) - always include excerpts when serializing topic lists
svg_iconsstring array - a list of icons which should be included in the icon subset
topic thumbnailsarray of dimensions - request additional resolutions in the topic thumbnail set. Note that they are generated asynchronously, so you must fall-back to the original image if your requested size is not provided. More information available in the commit message
One theme making heavy use of these new hooks is Topic List Thumbnails - check out the code to see how it works.
This document is version controlled - suggest changes on github.
David, probably a bit lazy of me to ask but is there any way to access this in a plugin:
Themes can request additional thumbnail sizes by using a modifier in their about.json file:
I will be attempting to migrate the TLP plugin to this new schema and it would be good to have the same access to features from a plugin, at least in the meantime.
David, what’s the right approach for BULK recreation of thumbnails?
I’ve just tried utilising on one of my sites and it seems to have processed about 10% of the Topics … then given up (or turned its nose up at the rest). Why I think it’s the former is that the Topics for whom Thumbnails were produced were the latest 10%.
Rebaking posts doesn’t seem to cut it. In fact, I did run a bulk rebake and wonder if that upset it …
I notice that image_url can be populated, but there are no thumbnails.
That column doesn’t do anything, and will be dropped very soon. image_upload_id is the one you want.
There should be no need for this. I deliberately designed it so that people can install new themes without having to mess around on the console. Thumbnails are generated asynchronously when needed. For example:
you add a new theme, which requests new resolutions
a user requests a topic, we serve the thumbnails that exist. If any sizes don’t exist, we schedule a sidekiq job.
next time someone requests the topic, the correct thumbnails will exist
If the requested thumbnail size is larger than the original, we won’t bother generate the thumbnail.
So the critical thing to bear in mind for this to work is:
There’s an example of this fallback logic in the thumbnail theme component I made - feel free to steal logic from there.
Yes that’s deliberate - we had a number of requests to remove small onebox thumbnails. For example, people were ending up with their github avatar as a topic thumbnail - which is rarely intended
Note that for oneboxes where the image is the actual content (such as instagram/twitter/etc photos), they will be selected.
That’s odd, build was more recent, but some still seem to be being overlooked.
Yeah, that’s partly why I ended up implementing a thumbnail picker for the situations where the automated choice wasn’t optimal. I may still want to modify that behaviour, but I will try to do so in the plugin.
Can we make it work for images from remote server as well? For example, images from Blogger, Picasa, or Amazon S3?
Because Discourse supports hosting on Amazon S3 for big and large image site, now if everything needs to be hosted on the local server directly then this design methodology seems to be a drawback.
With this update, it’s not an easy fix for my site since we’re using other server to host the images. Now it’s too difficult to move to an affiliated server with many posts, while it’s too big for hosting on local sever.
correct, this only works for local uploads… we may need to rethink that “max days old” setting 