Automatic thumbnails for Textpattern

phiw13 · 2025-12-09 05:43:13

This works much better now. My test articles from yesterday render the image as expected. Other of my tests (forms with <txp:images><img src="<txp:image_url thumbnail width="800" and the like) all render as expected.

Based on your list, some observations. Test images are:one portrait image and one landscape image

By default, aspect ratio is left blank in the preferences (for auto thumbnails)

<txp:article_image /> -> renders at full scale size UNLESS a custom thumbnail exists, then it uses the full scale image scaled to thumbnail

<txp:article_image thumbnail /> uses the (custom) thumbnail. If an auto thumbnail exists the image renders at full size. The width and height attributes are not specified.

<txp:article_image thumbnail width="200" /> custom thumbnail used if it exists, size as specified. The width attribute is specified.

<txp:article_image thumbnail="1" width="200" /> with auto thumbnails – no image. If a custom thumbnail exists, used at specified width, only width attribute is specified.

<txp:article_image thumbnail="2" width="200" /> a scaled full size image, width atribute is specified. (it does not matter here if aspect ratio is specified in the prefs, image is always scaled respecting its aspect ratio).

For the last one I also tested adding crop='1x1', images are cropped at the specified ratio.

–^–

Does this used the config.php setting for compression ? It is a little hard to say based on what the Network panel in Firefox tells.

define('TEXTPATTERN_THUMB_QUALITY', 60);

jakob · 2025-12-09 08:47:45

I gave your above sample a quick test with a custom and an automatic thumbnail:

Custom (user-defined) thumbnail

<txp:article_image />
Full-size image 3857 × 2751 px image rendered at width 450 × 300 px
(img attributes width="450" and height="300")

<txp:article_image width="200" />
Full-size 3857 × 2751 px image rendered at width 200 × 133 px
(img attributes width="200" and height="300". css height=“auto” overrides given dimensions)

<txp:article_image thumbnail width="200" />
Thumbnail image 450 × 300 px rendered at width 200 × 133 px
(img attributes width="200")

<txp:article_image thumbnail="1" width="200" />
Thumbnail image 450 × 300 px rendered at width 200 × 133 px
(img attributes width="200" and height="300")

<txp:article_image thumbnail="2" width="200" />
Thumbnail image generated and rendered at width 200 × 133 px with token
(img attributes width="200")

Automatically generated thumbnail

<txp:article_image />
Full-size image 6048 × 8064 px image rendered at width 1031 × 1375 px (container dimensions)
(no img attributes)

<txp:article_image width="200" />
Full-size 6048 × 8064 px image rendered at width 200 × 267 px, no token
(img attributes width="200")

<txp:article_image thumbnail width="200" />
Full-size image (9.jpg) 200 × 200 px not found (has token, see below)
(img attributes width="200")

<txp:article_image thumbnail="1" width="200" />
Thumbnail image (9t.jpg) specified and not found
(img attributes width="200")

<txp:article_image thumbnail="2" width="200" />
Full-size image (9.jpg) 200 × 267 px, with token, but the token is different to the one above
(img attributes width="200")

So, there are problems with two of the automatic thumbnails

Bloke · 2025-12-09 09:35:50

phiw13 wrote #341611:

This works much better now.

Awesome.

By default, aspect ratio is left blank in the preferences (for auto thumbnails)

Okay, this is perhaps where things are getting muddied. The settings in (theme) prefs currently reflect the situation for the admin-side only. i.e. the Images panel thumbs. They have zero effect on the public tags, so this probably explains some of your observations.

<txp:article_image /> -> renders at full scale size UNLESS a custom thumbnail exists, then it uses the full scale image scaled to thumbnail

Hmm, that feels wrong. Without the thumbnail attribute or dimensions, it should always use the full size image. I’ll take a look at this.

<txp:article_image thumbnail /> uses the (custom) thumbnail. If an auto thumbnail exists the image renders at full size. The width and height attributes are not specified.

This is, as far as I’m concerned, expected. If the custom thumbnail exists (i.e. the image has been told to use it by default from the Images panel), use it. If not, it will switch to display an automatic thumbnail. However, use of automatic thumbnails means a dimension or cropping factor is mandatory for it to trigger. In the absence of one of these attributes, the ‘thumbnail’ falls back on the fullsize pic.

If there’s a better, or more logical, approach to this, please speak up.

<txp:article_image thumbnail width="200" /> custom thumbnail used if it exists, size as specified. The width attribute is specified.

Yes. I should have actually chosen a different example size like 400, so it’s more obvious that it’s not falling back on the theme prefs or the constant, both of which are 200px, d’oh.

<txp:article_image thumbnail="1" width="200" /> with auto thumbnails – no image. If a custom thumbnail exists, used at specified width, only width attribute is specified.

Again, what I’d expect. It doesn’t throw any warnings that the custom thumbnail file doesn’t exist (becasue that is noise for the sake of it), it just silently tries and fails. But the existence of the dimensions in the HTML does cause it to take up (empty) space in the document, highlighting that it’s missing.

Again, is there any better way to handle this, do you think? What do you think most people would expect to (not) see?

<txp:article_image thumbnail="2" width="200" /> a scaled full size image, width atribute is specified. (it does not matter here if aspect ratio is specified in the prefs, image is always scaled respecting its aspect ratio).

Yes, that’s correct. Because the admin-theme prefs have no bearing on things on the public site. And as you found, if you (also/optionally) add crop="1x1" or crop="16x9" etc, you get the image shown at that ratio.

Does this used the config.php setting for compression?

It is supposed to use it, yes. I modded the core SLIR class to use it by default when a new image is made but i’ve also just forced it harder as fallback.

This is where I’m in a quandary. We could introduce a quality attribute to the image/article_image/image_url/thmbnail tags. But my reservation is that:

It only applies to automatic thumbnails, so using it when thumbnail="1" or when viewing the full scale image has no effect (because, in the case of the thumbnail, the quality is already pre-rendered from the admin-side). For the fullsize image, there’s no quality adjustment possible because no rescaling takes place: it’s a direct upload.
It only applies to certain image types. <txp:thumbnail name="time_machine.gif" quality="60" width="400" /> would have no effect.

The same thing affects changing the background alpha colour. SLIR supports them, but <txp:thumbnail name="time_machine.jpg" bg_colour="#0ff" width="400" /> would do nothing if we implemented that attribute.

Bloke · 2025-12-09 09:39:48

jakob wrote #341613:

So, there are problems with two of the automatic thumbnails

Thank you for the comprehensive tests. Investigating…

Bloke · 2025-12-09 10:14:44

Hmmm, some of the functionality experienced above might be related to our (perhaps daft) policy on using width/height:

width=“integer” v4.3.0+
Specify an image width which overrides the value stored in the database. Use width="0" to turn off the output of a width attribute in the <img> tag (thus the browser will scale the width if a height is used).
Default: width of image stored in the database.

Indeed, if width="0" is specified on an otherwise naked <txp:article_image /> tag, the full size image is returned and no width attribute is added to the <img> tag. That’s “correct” as per the docs (but whether it’s correct or logical to humans is debatable).

However, what I do feel is “wrong” is using the thumbnail’s dimensions by default when using the tag above. My feeling is that it should use the image dimensions, and only use the thumbnail sizes if you add a thumbnail attribute.

Consensus? If I changed this, it would not be very backwards compatible, but then my feeling is that it’s currently wrong in 4.8.8 anyway.

Last edited by Bloke (2025-12-09 10:15:51)

etc · 2025-12-09 10:55:56

Bloke wrote #341620:

Consensus? If I changed this, it would not be very backwards compatible, but then my feeling is that it’s currently wrong in 4.8.8 anyway.

Mined area. I’ve made some changes like this in 4.8.8… to discover that empty width is used more often than expected, so 4.9 restores (?) the 4.8.7 behaviour.

etc · 2025-12-09 11:01:42

One thing I’m not quite happy with, is the ‘virtual’ thumbnails directory. Seemingly, to resolve a thumbnail URL, the server needs to hit txp, even for already generated thumbnails. It would be more efficient (if possible security-wise) to do this redirection in .htaccess, or even expose a physical thumbnails address.

phiw13 · 2025-12-09 11:20:09

Bloke wrote #341620:

However, what I do feel is “wrong” is using the thumbnail’s dimensions by default when using the tag above. My feeling is that it should use the image dimensions, and only use the thumbnail sizes if you add a thumbnail attribute.

My expectation were / are that attribute less <txp:article_image /> will show the full, unscaled image, including the width/@height@ attributes as given by txp:image_info. Adding thumbnail would scale down to the given dimensions in the DB.

But of course, backwards compat waves to say hello.

Bloke · 2025-12-09 11:21:40

etc wrote #341622:

One thing I’m not quite happy with, is the ‘virtual’ thumbnails directory. Seemingly, to resolve a thumbnail URL, the server needs to hit txp, even for already generated thumbnails. It would be more efficient (if possible security-wise) to do this redirection in .htaccess, or even expose a physical thumbnails address.

The original implementation of SLIR does indeed introduce a custom .htaccess in its own physical directory. If you think that’s better to hard-code it, then cool. But it means Nginx can’t play out of the box so we’d need to make this feature Apache only somehow (i.e. hide the prefs, hide the theme prefs, etc etc). Not sure how we’d handle the security in that case. Rate limits instead of tokens?

Last edited by Bloke (2025-12-09 11:22:23)

Bloke · 2025-12-09 11:25:22

etc wrote #341621:

Mined area. I’ve made some changes like this in 4.8.8… to discover that empty width is used more often than expected, so 4.9 restores (?) the 4.8.7 behaviour.

Not sure. I don’t want to trample too much old code. But if you don’t specify you want to see a thumbnail (i.e. you expect the full image because you’ve not supplied any attributes to the contrary) it’s counterintuitive to see a scaled version just because you have made a physical thumbnail… isn’t it?

Bloke · 2025-12-09 11:55:02

I created a bunch of tests using an Article Image field with a range and some random images of different types (10-17, 36, 34, 6):

<txp:if_article_image>
<h3>Full article image</h3><txp:article_image /><br>
<h3>Full zero width article image</h3><txp:article_image width="0" /><br>
<h3>Scaled fullsize article image</h3><txp:article_image width="400" /><br>
<h3>Article image thumbs (default)</h3><txp:article_image thumbnail range /><br>
<h3>Scaled article image thumbs (default)</h3><txp:article_image thumbnail range width="400" /><br>
<h3>Custom article image thumbs (forced)</h3><txp:article_image thumbnail="1" range /><br>
<h3>Custom scaled article image thumbs (forced)</h3><txp:article_image thumbnail="1" range width="400" /><br>
<h3>Auto scaled article image thumbs (forced)</h3><txp:article_image thumbnail="2" range width="300" /><br>

<txp:images>
<h3>Full image</h3><txp:image />
<h3>Full zero width image</h3><txp:image width="0" />
<h3>Scaled fullsize image</h3><txp:image width="300" />
<h3>Thumb (default)</h3><txp:image thumbnail />
<h3>Scaled thumb (default)</h3><txp:image thumbnail width="250" />
<h3>Custom thumb (forced)</h3><txp:image thumbnail="1" />
<h3>Custom scaled thumb (forced)</h3><txp:image thumbnail="1" width="250" />
<h3>Auto scaled thumb (forced)</h3><txp:image thumbnail="2" width="200" />
</txp:images>
</txp:if_article_image>

The results seemed fairly consistent after applying the latest patch.

Is that any more logical, do you think? And does it work for your own tests?

One little irritation: you can’t output exactly the same thumbnail image with exactly the same dimensions/crop more than once on the same page, because the second token overwrites the first and causes it to become invalid. Hence the reason I’ve varied the image sizes throughout.

This isn’t an issue if the security feature is turned off. So, dunno. Depends if we think anyone is likely to want to display the same thumbnail image at the same size multiple times on the same page. Maybe a list view (sidebar) and an individual article_custom on the same page, perhaps? Although would they employ identical sizes in real applications? Hmmm.

Last edited by Bloke (2025-12-09 11:59:30)

etc · 2025-12-09 12:55:28

Bloke wrote #341625:

But it means Nginx can’t play out of the box so we’d need to make this feature Apache only

Dunno. People do run txp on nginx, so a .htaccess equivalent should be possible. It does not even has to be changed, perhaps, because the current rules say ‘if a file exists — grab it, otherwise go txp’. So it would suffice that a thumbnail image had src="images/cache/request/1ef6d72ecd924c5d9b59eeccb5cf7460" (say) to enable the direct access to cached images. And if it does not exist, txp takes the lead and creates it on the fly. Sure, I have not yet groked the security part of this stuff.

Bloke · 2025-12-09 13:07:44

Sure. Take a look at the .htaccess in the project repo. If you think a physical URL with something like that in it is better, then we can get rid of the pref.

From a security standpoint, the only thing we want to prevent is frivolous generation of cached images by directly hitting the /thumbnaildirectory. Once it’s cached I’m happy to bypass the tokenisation and serve the file directly. That’s how it should work.

It’s actually meant to do that already because I told SLIR to ignore imgtoken so as soon as there’s a cache hit for that, it should fetch the request or prerendered image. Maybe it’s not doing that?

Perhaps if, instead of always generating a token, if a request from a tag results in a cache hit, we just serve the direct image URL as you suggest.

That would also mean multiple hits for the same image on the same page would work because the URL goes direct to the pre-rendered content. I’d be much happier with that.

In theory, SLIR does all that out of the box with the supplied .htaccess (minus Nginx support) but it didn’t work for me. I got internal server errors due to the php_value statements and I have no idea why.

jakob · 2025-12-09 13:09:51

Bloke wrote #341627:

The results seemed fairly consistent after applying the latest patch.

Is that any more logical, do you think? And does it work for your own tests?

Hmm, still a few (what seem to me) anomalies.

For the custom (user-defined) thumbnail, the results are as before except for

<txp:article_image />
which shows the full-size image with
- correct full-size width attribute, but
- thumbnail height attribute (300) <- should this not be the full-size image height?

The automatic thumbnail is still as before. The means I get two non-loaded images for these two cases:

<!-- Render article image(s) as thumbnails scaled to 200px wide.
Use custom thumbs as the source if they exist, otherwise auto-generate them -->
<txp:article_image thumbnail width="200" />

<!-- Render article image(s) as thumbnails scaled to 200px wide.
Force custom thumbs (if they've been created) and scale them -->
<txp:article_image thumbnail="1" width="200" />

The first of those seem to be related to the “same width”-issue you mention above. That’s confirmed if I set the thumbnail to render at a different size.

The second occurs because there is no 9t.jpg image for automatically created images.

Depends if we think anyone is likely to want to display the same thumbnail image at the same size multiple times on the same page […] Although would they employ identical sizes in real applications? Hmmm.

A classic case of that might be a placeholder image.

jakob · 2025-12-09 13:12:28

Bloke wrote #341625:

The original implementation of SLIR does indeed introduce a custom .htaccess in its own physical directory. If you think that’s better to hard-code it, then cool. But it means Nginx can’t play out of the box so we’d need to make this feature Apache only somehow (i.e. hide the prefs, hide the theme prefs, etc etc). Not sure how we’d handle the security in that case. Rate limits instead of tokens?

No, it’s just great that it works out of the box with nginx.

Textpattern CMS support forum

#76 2025-12-09 05:43:13

Re: Automatic thumbnails for Textpattern

#77 2025-12-09 08:47:45

Re: Automatic thumbnails for Textpattern

Custom (user-defined) thumbnail

Automatically generated thumbnail

#78 2025-12-09 09:35:50

Re: Automatic thumbnails for Textpattern

phiw13 wrote #341611:

#79 2025-12-09 09:39:48

Re: Automatic thumbnails for Textpattern

jakob wrote #341613:

#80 2025-12-09 10:14:44

Re: Automatic thumbnails for Textpattern

#81 2025-12-09 10:55:56

Re: Automatic thumbnails for Textpattern

Bloke wrote #341620:

#82 2025-12-09 11:01:42

Re: Automatic thumbnails for Textpattern

#83 2025-12-09 11:20:09

Re: Automatic thumbnails for Textpattern

Bloke wrote #341620:

#84 2025-12-09 11:21:40

Re: Automatic thumbnails for Textpattern

etc wrote #341622:

#85 2025-12-09 11:25:22

Re: Automatic thumbnails for Textpattern

etc wrote #341621:

#86 2025-12-09 11:55:02

Re: Automatic thumbnails for Textpattern

#87 2025-12-09 12:55:28

Re: Automatic thumbnails for Textpattern

Bloke wrote #341625:

#88 2025-12-09 13:07:44

Re: Automatic thumbnails for Textpattern

#89 2025-12-09 13:09:51

Re: Automatic thumbnails for Textpattern

Bloke wrote #341627:

#90 2025-12-09 13:12:28

Re: Automatic thumbnails for Textpattern

Bloke wrote #341625:

Board footer