Automatic thumbnails for Textpattern

colak · Yesterday 09:51:10

I’ve been following this thread since it started, but admittedly, I had nothing to add.

Now that it is becoming more real, I have a question.

On txp classic, we have a full size image and a thumbnail. We can set up txp for the full size image to be 1420×600px and for the thumbnail to be 200×300px or whatever dimensions we want for the site design. If we do not like the automatically generated thumbnail, we have a choice of replacing it.

Will we have this type of functionality with this?

Bloke · Yesterday 10:10:35

colak wrote #341687:

On txp classic, we have a full size image and a thumbnail. We can set up txp for the full size image to be 1420×600px and for the thumbnail to be 200×300px or whatever dimensions we want for the site design. If we do not like the automatically generated thumbnail, we have a choice of replacing it. Will we have this type of functionality with this?

Forget any (automatic) thumbnail you decide to use for the admin side. It has no bearing on the site design. It’s only for you to see on the back-end, and the size of thumb is determined by the admin theme prefs (if the theme exposes them, otherwise it defaults to 200px square cropped).

On the public site your <txp:thumbnail width="400" /> (or whatever size you choose) determines the size of image you let visitors see. Each thumbnail is created at that size on the fly for you and cached.

If you want to override the automatic thumbnail creation and choose one of your own, like you do now, then that’s the only thumb size you’ll have available to your public site and your <txp:thumbnail /> tag will shrink and stretch that image as it does now.

Edit: although if you want to override it and use an automatic thumb at any time you can use something like <txp:image thumbnail="2" width="350" crop="2x3" /> to generate one with those dimensions on the fly.

Thumbnail = 0: no thumb.
Thumbnail = 1: custom thumb (as now).
Thumbnail = 2: automatic thumb (requires at least a width / height or crop attribute to function).

Last edited by Bloke (Yesterday 10:17:12)

colak · Yesterday 17:01:32

So, for our site, I will need to replace all <txp:thumbnail /> instances to <txp:image thumbnail="2" />?

It will not be a big chore, but it would be good to be prepared.

Bloke · Yesterday 17:48:21

colak wrote #341690:

So, for our site, I will need to replace all <txp:thumbnail /> instances to <txp:image thumbnail="2" />?

No, that won’t help. It can’t guess what size images you want. You need to tell it. You could take the opportunity to convert all your <txp:thumbnail /> tags to <img srcset=... > and put a bunch of <txp:thumbnail /> or <txp:image thumbnail /> tags at widths for each breakpoint. That would give your site a mobile step up and improve pagespeed.

As it stands, for backwards compatibility, nothing changes. You could choose to:

Manually override your image tags with thumbnail="2" width="400" which would force automatic thumbs at that width to be created.
Use the admin side multi-edit tool to convert a bunch of thumbnails to “automatic”. That means if you use <txp:thumbnail width="350" /> or <txp:image thumbnail width="350" /> (valueless thumbnail) on your site, it will use whatever “type” of thumbnail is set for that image, by default. Only if you specifically override the thumbnail attribute with a value will it try to render that specific type of thumbnail.

Does that clear things up a bit?

bici · Yesterday 23:50:34

this may or not be be applicable to the current work at hand. But is it possible to have sub-directories for the images directory?
For example if one wanted to load images that appear in a portfolio section to have their own directory for ease of identifying and managing etc.
eg.

/images/list of general images
and 
/images/portfolio/list of portfolio images

Bloke · Yesterday 23:55:08

bici wrote #341698:

is it possible to have sub-directories for the images directory?

Not at the moment. Having all the images in one directory is annoying and I’d love to one day find some sane method to load balance them (sections probably won’t work since you can assign multiple images to any section). But today is not that day, sadly.

Bloke · Today 02:29:48

Another step up in performance and functionality in this commit.

Image tokens are now:

Only generated if needed.
Assigned uniquely to thumbnails of the same dimensions/crop.

The upshot is:

Token generation is bypassed entirely if thumbnail exists for faster rendering.
A request for the same non-existent thumbnail multiple times will return the same token (no token invalidation) so multiple identical images will show up.
Browser cache should work better as the tokens are not used if the thumb exists.

Please take it for a spin, check you cannot create thumbnails by hacking, removing, mangling the token. And also, since I’ve messed around with the Token class, please check everything else that uses tokens (e.g. password reset requests, author creation activation emails, etc) still function correctly.

Thank you.

bici · Today 02:42:59

Bloke wrote #341699:

Not at the moment. Having all the images in one directory is annoying and I’d love to one day find some sane method to load balance them (sections probably won’t work since you can assign multiple images to any section). But today is not that day, sadly.

no worries. full steam ahead and all the best!

phiw13 · Today 03:06:35

Bloke wrote #341701:

Another step up in performance and functionality in this commit.

Image tokens are now:

Only generated if needed.

Assigned uniquely to thumbnails of the same dimensions/crop.

The upshot is:

Token generation is bypassed entirely if thumbnail exists for faster rendering.

A request for the same non-existent thumbnail multiple times will return the same token (no token invalidation) so multiple identical images will show up.

Browser cache should work better as the tokens are not used if the thumb exists.

Sounds great. I will test further.

Funny, a few moment before you posted I had started drafting a now obsolete Q about this: browser A access page / image, get the thumbnail with token. ~3 minutes later browser B accesses the same page / image (with same window size e.a.), but get the thumbnail with a different token. Is (or was) that the same image or a different generated one? Looking at the file system, only one image exists. That was with code before your latest update above.

The latest commit should indeed improve performance (for the browser: better caching, perhaps less work as it does not need to parse the token) and for the filesystem.

Please take it for a spin, check you cannot create thumbnails by hacking, removing, mangling the token. And also, since I’ve messed around with the Token class, please check everything else that uses tokens (e.g. password reset requests, author creation activation emails, etc) still function correctly.

I’ll checking a few things locally, the email thing is not possible. Should I update the “live” test site?

jakob · Today 10:18:16

Gave it a quick whirl on my local install with Helo catching local emails. And … it seems great!

Can confirm, after removing my /images/thumb/cache folder…

On first load a thumbnail image is generated in the correct width with a token appended to the image src url 👌
On first load, two images with identical dimensions both show. The generation tokens for both are identical 👌
On reload, the already generated thumbnail image is fetched directly from the cache/…/ folder, no token 👌
Creating a new user still works 👍
Resetting a password still works 👍

Other notes

As mentioned off-forum, it’s not important, just a neatness thing: is it vital to have the …/cache/rendered/… in the actual image url (even if txp ultimately fetches the image from there)?
There is that (legacy?) weirdness where txp:article_image outputs the thumbnail @height=“300”… attribute in place of the main image’s height. 🤔

So for an image with original dimensions 3857×2571 and a custom thumbnail of size 450×300 I get:

<!-- <txp:article_image /> -->
<!-- Render article image(s) as full size pics -->
<img src="http://thumbnail.test/images/13.jpg" alt="…" width="3857" height="300">

<!-- <txp:article_image width="200" /> -->
<!-- Render article image(s) as full size pics, scaled to 200px wide -->
<img src="http://thumbnail.test/images/13.jpg" alt="…" width="200" height="300">

<!-- <txp:article_image thumbnail width="200" /> -->
<!-- Render article image(s) as thumbnails scaled to 200px wide.
Use custom thumbs as the source if they exist, otherwise auto-generate them -->
<img src="http://thumbnail.test/images/13t.jpg" alt="…" width="200">

<!-- <txp:article_image thumbnail="1" width="200" /> -->
<!-- Render article image(s) as thumbnails scaled to 200px wide.
Force custom thumbs (if they've been created) and scale them -->
<img src="http://thumbnail.test/images/13t.jpg" alt="…" width="200" height="300">

<!-- <txp:article_image thumbnail="2" width="200" /> -->
<!-- Render article image(s) as thumbnails scaled to 200px wide.
Force auto-generated thumbs to be created -->
<img src="http://thumbnail.test/images/thumb/cache/rendered/w200/13.jpg" alt="" width="200">

The 3rd and 5th variants get it right, the others steadfastly output 300 regardless of whether the original image or the downsized thumbnail.

As I mentioned off-forum, this also means to get an img src output of the article_image with a correct width and height, you have to manually construct the img tag:

<txp:images id='<txp:custom_field name="article_image" />'>
    <img src="<txp:image_url />" alt="<txp:image_info type="alt" />" width="<txp:image_info type="w" />" height="<txp:image_info type="h" />">
</txp:images>

or at the minimum, suppress the height output with:

<txp:article_image height="0" />

Aside from all that, though … blooming excellent!!

Is there anything else I should test?

—-

PS: For anyone interested, the (apparent) problem I mentioned in an earlier post about other srcset images not being loaded on viewport resize turns out to be a browser inconsistency issue that I was unaware of up to now:

Blink-based browsers (Chrome, Brave, Edge etc.) will load successively larger image sizes in a srcset as the viewport widens, but if a larger image already exists, it doesn’t load smaller sizes when downsizing the viewport.
Webkit-based browsers (Safari, DuckDuckGo, Orion etc.) will load the best-fit image size in a srcset on load, but not other srcset images on upsizing/downsizing viewport width. [this is what caught me out]
Gecko-based browsers (Firefox etc.) will load successively larger and smaller image sizes in a srcset when upsizing and downsizing the viewport width.

For those interested, Ian Duffy tested this more extensively …

jakob · Today 10:36:16

colak wrote #341687:

On txp classic, we have a full size image and a thumbnail. We can set up txp for the full size image to be 1420×600px and for the thumbnail to be 200×300px or whatever dimensions we want for the site design. If we do not like the automatically generated thumbnail, we have a choice of replacing it. Will we have this type of functionality with this?

Just to clarify, because I think there may have been crossed wires further up the thread…

As far as I understand it – and please correct me @bloke, @etc if I’m wrong – if you upgrade an existing site that has its own already prepared thumbnails, nothing changes. You can continue running the site as before with what are now called “custom”, i.e. user-defined thumbnails. I think the same applies to users of smd_thumbnails too (though you might need to check that your chosen smd_thumbnail subdirectory names don’t clash with those used by the new system).

Also, the thumbnails that Textpattern has up to now “automatically” created for you and saved with a t on the end, 123t.jpg – and which you can choose to overwrite with a thumbnail you have created yourself – still count as custom (user-defined) thumbnails.

The new automatic thumbnailing facility – if you choose to use it – bypasses the 123t.jpg files entirely and creates its own thumbnails on the fly when you specify the thumbnail attribute and a width and/or crop attribute in the various txp:image tags.

Long story short: my understanding is that you will not need to change your site when upgrading, unless you decide to switch to using automatic thumbnails.

Bloke · Today 11:09:11

Glad it’s working mostly. Thank you so much for testing.

I’ll see if I can tame the extra /cache/rendered file path now we’re not using the request cache.

As for the height thing, it’s kind of by design unfortunately. If you only override one of the dimensions, it leaves the other intact (read from the database) unless you explicitly set it to “0” (i.e. “I don’t want it”).

We could break bwc and change it. Thoughts?

Textpattern CMS

Textpattern CMS support forum

#133 Yesterday 09:51:10

Re: Automatic thumbnails for Textpattern

#134 Yesterday 10:10:35

Re: Automatic thumbnails for Textpattern

colak wrote #341687:

#135 Yesterday 17:01:32

Re: Automatic thumbnails for Textpattern

#136 Yesterday 17:48:21

Re: Automatic thumbnails for Textpattern

colak wrote #341690:

#137 Yesterday 23:50:34

Re: Automatic thumbnails for Textpattern

#138 Yesterday 23:55:08

Re: Automatic thumbnails for Textpattern

bici wrote #341698:

#139 Today 02:29:48

Re: Automatic thumbnails for Textpattern

#140 Today 02:42:59

Re: Automatic thumbnails for Textpattern

Bloke wrote #341699:

#141 Today 03:06:35

Re: Automatic thumbnails for Textpattern

Bloke wrote #341701:

#142 Today 10:18:16

Re: Automatic thumbnails for Textpattern

#143 Today 10:36:16

Re: Automatic thumbnails for Textpattern

colak wrote #341687:

#144 Today 11:09:11

Re: Automatic thumbnails for Textpattern

Board footer