Automatic thumbnails for Textpattern

etc · 2025-12-20 23:17:47

Well, I go to bed ©

Bloke · 2025-12-21 00:36:41

A few tests so far between article_image and image (wrapped with <txp:images>) yields:

Full size images, both render fine.
<txp:article_image />
<img src="https://example.com/images/210.webp" alt="" width="5760" height="3840">
<txp:image />
<img src="https://example.com/images/210.webp" alt="">

Article image fine, regular image too small to see. I would expect the image tag to use the full DB width.
<txp:article_image width />
<img src="https://example.com/images/210.webp" alt="" width="5760">
<txp:image width />
<img src="https://example.com/images/210.webp" alt="" width="1">

Ditto, with DB width and height used for image tag.
<txp:article_image width height />
<img src="https://example.com/images/210.webp" alt="" width="5760" height="3840">
<txp:image width height />
<img src="https://example.com/images/210.webp" alt="" width="1" height="1">

Full size, because no dimensions are used.
<txp:article_image crop />
<img src="https://example.com/images/210.webp" alt="">
<txp:image crop />
<img src="https://example.com/images/210.webp" alt="">

Full size, no dimensions. Fine.
<txp:article_image width="0" />
<img src="https://example.com/images/210.webp" alt="">
<txp:image width="0" />
<img src="https://example.com/images/210.webp" alt="">

Expected.
<txp:article_image width="0" height />
<img src="https://example.com/images/210.webp" alt="" height="3840">
<txp:image width="0" height />
<img src="https://example.com/images/210.webp" alt="" height="1">

Article thumb defaults to fallback sizes. Regular thumb uses 't' (custom).
<txp:article_image thumbnail />
<img src="https://example.com/images/210.webp" alt="" width="160" height="160">
<txp:image thumbnail />
<img src="https://example.com/images/210t.webp" alt="">

Article image cannot be rendered (out of memory). Regular image too small to see.
<txp:article_image thumbnail width />
<img src="https://example.com/images/thumb/w5760/210.webp?token=56e0c6e2..." alt="" width="5760">
<txp:image thumbnail width />
<img src="https://example.com/images/thumb/w1/210.webp" alt="" width="1">

Ditto.
<txp:article_image thumbnail width height />
<img src="https://example.com/images/thumb/w5760-h3840/210.webp?token=7b25fec4f..." alt="" width="5760" height="3840">
<txp:image thumbnail width height />
<img src="https://example.com/images/thumb/w1-h1/210.webp" alt="" width="1" height="1">

Fine.
<txp:article_image thumbnail width="300" />
<img src="https://example.com/images/thumb/w300/210.webp?token=7db2a7abc..." alt="" width="300">
<txp:image thumbnail width="300" />
<img src="https://example.com/images/thumb/w300/210.webp?token=7db2a7abc..." alt="" width="300">

Article image fine. Regular image is a solid rectangle of colour. Different tokens (as expected).
<txp:article_image thumbnail width="300" height />
<img src="https://example.com/images/thumb/w300-h3840/210.webp?token=8d8541c72..." alt="" width="300" height="3840">
<txp:image thumbnail width="300" height />
<img src="https://example.com/images/thumb/w300-h1/210.webp?token=0bedbcfa1c..." alt="" width="300" height="1">

Fine.
<txp:article_image thumbnail width="300" height="240" />
<img src="https://example.com/images/thumb/w300-h240/210.webp?token=44102bac..." alt="" width="300" height="240">
<txp:image thumbnail width="300" height="240" />
<img src="https://example.com/images/thumb/w300-h240/210.webp?token=44102bac..." alt="" width="300" height="240">

Fine.
<txp:article_image thumbnail width="300" height="240" crop="1x1.smart" />
<img src="https://example.com/images/thumb/w300-h240-c1x1.smart/210.webp?token=ee4e683..." alt="" width="300" height="240">
<txp:image thumbnail width="300" height="240" crop="1x1.smart" />
<img src="https://example.com/images/thumb/w300-h240-c1x1.smart/210.webp?token=ee4e683..." alt="" width="300" height="240">

Fine.
<txp:article_image thumbnail crop="1x1.smart" />
<img src="https://example.com/images/thumb/c1x1.smart/210.webp?token=5bf6d32..." alt="">
<txp:image thumbnail crop="1x1.smart" />
<img src="https://example.com/images/thumb/c1x1.smart/210.webp?token=5bf6d32..." alt="">

Renders nothing if no custom thumb (as expected).
<txp:article_image thumbnail="1" width="300" height />
<img src="https://example.com/images/210t.webp" alt="" width="300" height="160">
<txp:image thumbnail="1" width="300" height />
<img src="https://example.com/images/210t.webp" alt="" width="300" height="1">

Ditto.
<txp:article_image thumbnail="1" width="300" height="240" />
<img src="https://example.com/images/210t.webp" alt="" width="300" height="240">
<txp:image thumbnail="1" width="300" height="240" />
<img src="https://example.com/images/210t.webp" alt="" width="300" height="240">

Fine.
<txp:article_image thumbnail="2" width="300" height="240" />
<img src="https://example.com/images/thumb/w300-h240/210.webp" alt="" width="300" height="240">
<txp:image thumbnail="2" width="300" height="240" />
<img src="https://example.com/images/thumb/w300-h240/210.webp" alt="" width="300" height="240">

Fine.
<txp:article_image thumbnail="2" width="300" height="240" quality="40" />
<img src="https://example.com/images/thumb/w300-h240-q40/210.webp?token=440e9934..." alt="" width="300" height="240">
<txp:image thumbnail="2" width="300" height="240" quality="40" />
<img src="https://example.com/images/thumb/w300-h240-q40/210.webp?token=440e9934..." alt="" width="300" height="240">

Looks reasonable so far, aside from the <txp:image> (and, by inference, the <txp:image_url> tag) tag not outputting the DB dimensions when used valueless.

Are we comfortable that these are backwards-compatible enough to avoid nasty surprises in most situations, bearing in mind that many people won’t be using the attributes in these ways, because some of the combos weren’t very logical or useful before?

etc · 2025-12-21 11:52:02

Compare with 4.8.8, maybe?

Bloke · 2025-12-21 12:02:25

Yeah, on it.

I’m tempted to add in valueless width/height to the main <txp:image(_url) tags so they use the DB values, and just run with it. We should be doing that for valueless attributes anyway and it doesn’t have any b/c issues since we don’t support it in 4.8.8. and below.

phiw13 · 2025-12-26 06:47:14

Bloke wrote #341823:

That’s a ~~feature~~ bug in the way we handle uploads. We only switch the dimensions given by the orientation info for thumbnails (custom and automatic).

[…]

Edit: I presume only jpg images are affected by this? How do webp, PNG and avif etc handle orientation?

Regarding rotating (switching) dimensions for full scale images on uploads

I suspect only jpg files are affected. I don’t think .webp and PNG images have an orientation meta data chunk the way jpg does.

2 links that might help: (verbiage is a little above my paygrade)

jakob · 2025-12-27 19:41:09

I’m trying the automatic thumbnails on a new host and not getting them at all, neither on the front-facing page nor on the admin-side. How do I start debugging?

Things I’ve looked at:

Diagnostics: no errors or restrictions listed. Just the notice: You have PHP enabled in your articles/pages.
Diagnostics: PHP 8.5 – GD 2.3.3 / GIF / JPEG / PNG / WebP – nginx/1.28.0
Textpattern 4.9 release version
php-fpm log: no errors listed
The /images/ and /thumb/ folders are writable. This server makes all folders with the rights 0770. I upped the images and thumb folders to 0777 for now. Uploading images and files works fine. The owner is the same as the rest of the site.

Creating a custom thumbnail works. The automatic thumbnails don’t. Images are uploaded but the thumbnails are not created in the /images/thumb/. The w800 folder is also not created.

The page source shows the link with token:

https://domain.com/images/thumb/w800/1.jpg?token=8140119e540a03e3fa8a0f587490f68f22e99ff0bfa06d4297ec1bacf1fd8e48

This is what the browser answers:

Übersicht
URL: https://domain.com/images/thumb/w800/1.jpg?token=8140119e540a03e3fa8a0f587490f68f22e99ff0bfa06d4297ec1bacf1fd8e48
Status: 404
Quelle: Netzwerk
Adresse: xxx.xxx.xxx.xxx:443
Initiator: 
welcome-to-textpattern:740

Anfrage
:method: GET
:scheme: https
:authority: domain.com
:path: /images/thumb/w800/1.jpg?token=8140119e540a03e3fa8a0f587490f68f22e99ff0bfa06d4297ec1bacf1fd8e48
Accept: image/webp,image/avif,image/jxl,image/heic,image/heic-sequence,video/*;q=0.8,image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5
Accept-Encoding: gzip, deflate, br
Accept-Language: de-DE,de;q=0.9
Cache-Control: no-cache
Cookie: txp_login_public=986048ffd3julian; PHPSESSID=e310c00047975644b7a08ef70a222c94
Pragma: no-cache
Priority: u=3, i
Referer: https://domain.com/articles/welcome-to-textpattern
Sec-Fetch-Dest: image
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: same-origin
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.2 Safari/605.1.15

Antwort
:status: 404
Content-Encoding: br
Content-Type: text/html
Date: Sat, 27 Dec 2025 19:19:52 GMT
Server: nginx
Vary: Accept-Encoding

Parameter der Abfragezeichenkette
token: 8140119e540a03e3fa8a0f587490f68f22e99ff0bfa06d4297ec1bacf1fd8e48

In the network panel it says Type: html (not jpg). Could there be a problem with the mime-type handling? Or the 404-handling preventing redirection to the image?

Aside: I think this is unrelated, but I noticed that some of the files in the /vendors/lencioni/ folder have different permissions. Some are 0640 and some 0750. Locally they are 644 / 755. Changing them had no effect.

Bloke · 2025-12-27 20:16:59

Right click a thumbnail that purports to be automatic (i.e. has /thumb/w800/… in it) and open in a new tab. If the process is failing you should see an error message in the browser.

jakob · 2025-12-27 23:00:39

I get a 404 and this page source:

<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>
</html>

and this response:

Übersicht
URL: https://domain.com/images/thumb/w800/1.jpg?token=8140119e540a03e3fa8a0f587490f68f22e99ff0bfa06d4297ec1bacf1fd8e48
Status: 404
Quelle: Netzwerk
Adresse: xxx.xxx.xxx.xxx:443

Anfrage
:method: GET
:scheme: https
:authority: domain.com
:path: /images/thumb/w800/1.jpg?token=8140119e540a03e3fa8a0f587490f68f22e99ff0bfa06d4297ec1bacf1fd8e48
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: de-DE,de;q=0.9
Cookie: txp_login_public=986048ffd3julian; PHPSESSID=e310c00047975644b7a08ef70a222c94
Priority: u=0, i
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.2 Safari/605.1.15

Antwort
:status: 404
Content-Encoding: br
Content-Type: text/html
Date: Sat, 27 Dec 2025 22:59:58 GMT
Server: nginx
Vary: Accept-Encoding

Parameter der Abfragezeichenkette
token: 8140119e540a03e3fa8a0f587490f68f22e99ff0bfa06d4297ec1bacf1fd8e48

jakob · 2025-12-27 23:43:16

I think I’ve identified it as a problem in the default nginx vhost that I don’t quite understand yet.

It has a section as follows:

  location ~* ^.+\.(css|js|jpg|jpeg|gif|png|ico|gz|svg|svgz|ttf|otf|woff|woff2|eot|mp4|ogg|ogv|webm|webp|zip|swf|map|mjs)$ {
    add_header Access-Control-Allow-Origin "*";
    add_header alt-svc 'h3=":443"; ma=86400';
    expires max;
    access_log off;
  }

Removing jpg|jpeg from that list allows the images to appear. I need to learn what that means and then see what I should correct or exclude from that. But that’s a problem for tomorrow.

EDIT: Additional observations after further investigation:

Normal images seem to be handled just fine, so it looks like just the initial redirect to thumbnail creation situation that occurs when a token is passed isn’t being handled. To test that, I temporarily removed the image extensions from that list allows txp to create the thumbs, then restored the original nginx directive including the image extensions. The thumbnails created in the /images/thumb/…directories now work, just the new creation of thumbs doesn’t.

@gaekward or anyone else? Is there a way of either passing through image requests that result in a 404 or 301 to the thumbnail creation routine, and / or is there a way of excluding location regexs that contain a ?token= url parameter from this directive?

Bloke · 2026-01-15 20:32:52

[I split bici’s questions about the custom thumbnails to their own topic.

Bloke · 2026-01-22 20:19:16

A couple of recent commits of note here. Firstly, I’ve allowed you to specify your own memory_limit (in MB) via your config.php. For anyone who is using larger source images and doesn’t mind the wait time (and potential crashage of the server due to overloading it), feel free to bump this up or down for performance. If you find a bunch of thumbs are not being created, it may be the automatic generator is maxing out.

The best solution in this situation is to batch process your images to slightly lower resolution prior to uploading them to the Images panel, but if you absolutely must have super hi-res images, tweaking this value might help.

Secondly, I found that subdir installations now fail to create thumbs if the subdir is also part of the site_url. It resulted in duplication of the overlapping portion so this commit tries to rectify that. I’m especially interested if it still works for your virtual host environment, Robert, since I don’t have a setup here that simulates that. Hopefully it carries on working but if it breaks, please let me know what values you’re seeing in the URLs compared with what you expect and I’ll try and figure it out.

Bloke · 2026-01-23 01:00:44

Since we can’t really have 4.9.1 solely with bug fixes and minor changes, how about one feature I didn’t have time to squeeze into 4.9.0? The ability to alter the output format of automatic thumbnails.

Say you have a jpg original uploaded but want to serve different formats at different resolutions via srcset thumbs and a fallback for older browsers? No problem now:

<txp:images>
   <picture>
     <source srcset="<txp:image_url thumbnail width="200" type="webp" /> 1x, <txp:image_url thumbnail width="400" type="webp" /> 2x" type="image/webp">
     <img src="<txp:image_url thumbnail width="300" type="png" />" alt="<txp:image_info type="alt" />">
   </picture>
</txp:images>

Obviously it can’t work miracles. If you expect a transparent png to render as a jpg, you might be surprised. AVIF support is sketchy depending on what your server is compiled with. And of course you can’t expect a regular image to be converted to SVG, so that’s outlawed as a type. But otherwise, go nuts.

There is an annoying caveat: the file extension of the image in the cache won’t change to reflect the actual format. It will continue to use the original file extension (although if you right click and Save As, it will download it in the correct format with the correct extension). There might be a way round this, and the purist in me will try and find one, but I’m not sure if it will be possible because it’s ‘looking for’ a file with an extension as given in the database. It may also invalidate the cache because it’s expecting a file with the original extension to be generated. I’ll have a play anyway.

In the meantime, please test this to see how well (or otherwise) it works. And please do check thumbs of different formats aren’t freshly generated each time. They should still be fetched from the cache with a 304 if they have already been created, regardless that the file extension isn’t correct.

wet · 2026-01-23 12:50:27

Bloke wrote #342338:

… I’m especially interested if it still works for your virtual host environment, Robert, since I don’t have a setup here that simulates that. Hopefully it carries on working…

It does :)

phiw13 · 2026-01-23 13:18:57

Bloke wrote #342342:

Since we can’t really have 4.9.1 solely with bug fixes and minor changes, how about one feature I didn’t have time to squeeze into 4.9.0? The ability to alter the output format of automatic thumbnails.

[…]

The good news is it doesn’t create problems with/on my existing image markup :-) I haven’t had time/energy to test any further.

Can it be that the part you already had merged into dev earlier today a reason why no automatic thumbnails are created (5.0-dev only)? I need to create a clean new install to test more.

Edit but there is, in the thumbnail column, an place holder frame similar to a missing mage.

Last edited by phiw13 (2026-01-23 13:22:30)

Bloke · 2026-01-23 13:36:57

This might be related to what Robert is seeing and could well be the change yesterday.

It should default to using the same mime type, and thus extension, as the stored image.

I’ll have a poke around. Thanks for checking it out.

Textpattern CMS

Textpattern CMS support forum

#271 2025-12-20 23:17:47

Re: Automatic thumbnails for Textpattern

#272 2025-12-21 00:36:41

Re: Automatic thumbnails for Textpattern

#273 2025-12-21 11:52:02

Re: Automatic thumbnails for Textpattern

#274 2025-12-21 12:02:25

Re: Automatic thumbnails for Textpattern

#275 2025-12-26 06:47:14

Re: Automatic thumbnails for Textpattern

Bloke wrote #341823:

#276 2025-12-27 19:41:09

Re: Automatic thumbnails for Textpattern

#277 2025-12-27 20:16:59

Re: Automatic thumbnails for Textpattern

#278 2025-12-27 23:00:39

Re: Automatic thumbnails for Textpattern

#279 2025-12-27 23:43:16

Re: Automatic thumbnails for Textpattern

#280 2026-01-15 20:32:52

Re: Automatic thumbnails for Textpattern

#281 2026-01-22 20:19:16

Re: Automatic thumbnails for Textpattern

#282 2026-01-23 01:00:44

Re: Automatic thumbnails for Textpattern

#283 2026-01-23 12:50:27

Re: Automatic thumbnails for Textpattern

Bloke wrote #342338:

#284 2026-01-23 13:18:57

Re: Automatic thumbnails for Textpattern

Bloke wrote #342342:

#285 2026-01-23 13:36:57

Re: Automatic thumbnails for Textpattern

Board footer