Automatic thumbnails for Textpattern

Bloke · 2025-12-08 11:11:53

phiw13 wrote #341605:

Uncaught Error: Call to undefined function imageBuild()@. .

That’s strange. The calls to include the admin-side library are both in place:

github.com/textpattern/textpattern/blob/dev/textpattern/publish.php#L842
github.com/textpattern/textpattern/blob/dev/textpattern/publish.php#L868

🤔🤔

Edit: Ah wait, maybe article_image needs to know about this too. I’ll check.

Last edited by Bloke (2025-12-08 11:13:17)

Bloke · 2025-12-08 15:36:24

~~Try this and see if the error goes away.~~

Edit: no, wait. Needs more consolidation. Bear with me while I get the code aligned with the image tag.

Thanks for the report.

Last edited by Bloke (2025-12-08 16:30:01)

Bloke · Yesterday 01:04:52

Okay, I think that’s better. <txp:article_image>, <txp:thumbnail> and <txp:image thumbnail> are now more closely in step.

If you use a valueless thumbnail it will use the most appropriate thumbnail as defined in the database. So if an image is specifed as type=“auto” (a.k.a. Type 2) then you’ll see an automatically generated thumb – assuming you specify some dimension or crop values. But if your image is type 1 (custom thumbnail) you’ll see the IDt.ext version (if it exists), scaled accoprding to the width/height attribute.

You can override this by specifying a particular thumbnail value. If you don’t specify dimensions for an auto-generated thumbnail, you’ll get the full size image. And if you specify dimensions for a full size image, it will be scaled accordingly.

Here are some examples of the various options:

<!-- Render article image(s) as full size pics -->
<txp:article_image />

<!-- Render article image(s) as full size pics, scaled to 200px wide -->
<txp:article_image 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 -->
<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" />

<!-- Render article image(s) as thumbnails scaled to 200px wide.
Force auto-generated thumbs to be created -->
<txp:article_image thumbnail="2" width="200" />

Please play with as many article_image/image/thumbnail tags and combinations as you can think of, with and without dimensions, with width="" and/or height="" (which should still remove the width and height attributes from the resulting img tag) and see if the output matches your expectations.

Last edited by Bloke (Yesterday 01:09:44)

phiw13 · Yesterday 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 · Yesterday 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 · Yesterday 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 · Yesterday 09:39:48

jakob wrote #341613:

So, there are problems with two of the automatic thumbnails

Thank you for the comprehensive tests. Investigating…

Bloke · Yesterday 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 (Yesterday 10:15:51)

etc · Yesterday 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 · Yesterday 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 · Yesterday 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 · Yesterday 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 (Yesterday 11:22:23)

Textpattern CMS

Textpattern CMS support forum

#73 2025-12-08 11:11:53

Re: Automatic thumbnails for Textpattern

phiw13 wrote #341605:

#74 2025-12-08 15:36:24

Re: Automatic thumbnails for Textpattern

#75 Yesterday 01:04:52

Re: Automatic thumbnails for Textpattern

#76 Yesterday 05:43:13

Re: Automatic thumbnails for Textpattern

#77 Yesterday 08:47:45

Re: Automatic thumbnails for Textpattern

Custom (user-defined) thumbnail

Automatically generated thumbnail

#78 Yesterday 09:35:50

Re: Automatic thumbnails for Textpattern

phiw13 wrote #341611:

#79 Yesterday 09:39:48

Re: Automatic thumbnails for Textpattern

jakob wrote #341613:

#80 Yesterday 10:14:44

Re: Automatic thumbnails for Textpattern

#81 Yesterday 10:55:56

Re: Automatic thumbnails for Textpattern

Bloke wrote #341620:

#82 Yesterday 11:01:42

Re: Automatic thumbnails for Textpattern

#83 Yesterday 11:20:09

Re: Automatic thumbnails for Textpattern

Bloke wrote #341620:

#84 Yesterday 11:21:40

Re: Automatic thumbnails for Textpattern

etc wrote #341622:

Board footer