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?

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:

Board footer