Feedback: Textpattern CMS 4.9.0 released

Bloke · 2026-01-05 01:16:00

Bloke wrote #341937:

There has to be some middle ground approach somehow which satisfies both goals of allowing valueless widths and heights to output the stored image dimensions, but ignore the stored information if the attribute is not provided.

Okay, I’ve had another stab at dimension taming. What happens now (and I think this is closer to how people actually use the tags) is:

The default width and height settings for <txp:article_image/>, <txp:image>, <txp:thumbnail> and <txp:image_url> is width="0" height="0". The upshot of this is that no dimensions are output at all unless you add the attributes.
Specifying any actual value for a width= or height= will always use that value.
Specifying valueless width or height will import that dimension from the database. If you’re displaying a full-size image, it will be the native dimension values. If you’re displaying a custom thumb, it’ll be the native thumbnail dimensions of whatever size you chose when you created it. If you’re displaying an automatic thumbnail, it will be the TEXTPATTERN_THUMB_WIDTH/HEIGHT value (which is 160 by default, but overridable in your config.php).

I think (hope) that is more logical and should tame some of these ridiculous stretched images we see in 4.9.0 that require height="0" to fix them.

Please test and report back, thank you.

Bloke · 2026-01-05 01:18:35

Bloke wrote #342065:

self::$documentRoot = $path_to_site

I changed this too, so please test that the thumbs are still created in the correct location. It should hopefully resolve wet’s issue and allow multiple virtual hosts to resolve to the correct filesystem image path.

wet · 2026-01-05 04:29:32

Bloke wrote #342083:

I changed this too […] It should hopefully resolve wet’s issue and allow multiple virtual hosts to resolve to the correct filesystem image path.

Works for me, indeed. Thanks a lot!

phiw13 · 2026-01-05 07:28:52

Bloke wrote #342082:

Okay, I’ve had another stab at dimension taming. What happens now (and I think this is closer to how people actually use the tags) is:

thank you for that. In a first round of testing, including some of my frequently used blocks of image shortcode, this works nicely now. RM the forced use height=0 ! I definitely like that.

[…] If you’re displaying an automatic thumbnail, it will be the TEXTPATTERN_THUMB_WIDTH/HEIGHT value (which is 160 by default, but overridable in your config.php).

Could you explain that a little more ? It is not clear how to trigger this

I think (hope) that is more logical and should tame some of these ridiculous stretched images we see in 4.9.0 that require height="0" to fix them.

And smd_where_used to the rescue again to find where I did use it. The good thing is, keeping it in place does the same as omitting the height attribute. Those like me who already use the automatic generation do not need to hurry after updating.

bici · 2026-01-05 16:15:42

phiw13 wrote #342089:

And smd_where_used to the rescue again to find where I did use it. The good thing is, keeping it in place does the same as omitting the height attribute. Those like me who already use the automatic generation do not need to hurry after updating.

I have downloaded it and installed it. but for the life me I can’t see how I use it to search? On Pages Forms, I don’t see any search bar.

Bloke · 2026-01-05 16:35:17

bici wrote #342096:

I have downloaded it and installed it. but for the life me I can’t see how I use it to search?

Extensions>Where Used.

bici · 2026-01-05 18:53:59

Bloke wrote #342097:

Extensions>Where Used.

🤓. thankfully I am getting cataract surgery this month…. and it might improve my sight!

Bloke · 2026-01-06 00:52:08

phiw13 wrote #342089:

thank you for that. In a first round of testing, including some of my frequently used blocks of image shortcode, this works nicely now. RM the forced use height=0 ! I definitely like that… The good thing is, keeping it in place does the same as omitting the height attribute. Those like me who already use the automatic generation do not need to hurry after updating.

Sweet, thank you for testing. Glad it’s more natural now. And there’s a suitable upgrade path with low pain point.

Could you explain [TEXTPATTERN_THUMB_WIDTH] a little more ? It is not clear how to trigger this

Ack, I kind of lied. I thought it was applied across the board, but it seems not. It currently only uses the fallback values if you use <txp:article_image thumbnail="2"> (or your thumb is already designated ‘automatic’ on the admin side Image Edit panel). And even then, only if there’s no custom thumb been defined for it in the past (i.e. a complete absence of a ‘NNt.ext’ file).

I don’t like this inconsistency. The config parameters were really only designed to be used for the admin side, so I’m tempted to ditch their fallback usage in the public tags. This would mean, if you specify valueless width or height in your public tags and the thumbnail dimension is missing (i.e. no thumb_w / thumb_h value in the database) you’ll get the natural full image dimension output. Seems more sensible than a config variable. And I suspect most people won’t use this feature anyway, electing to define one of the dimensions in their tag attributes and have the other auto scaled by omitting it.

The question mark hangs over ‘crop’. If we don’t explicitly handle valueless crop, it will default to 1 if you don’t specify a value. Which is an invalid crop ratio, and your image will not be rendered. That feels buggy, so I’ve kludged it just now for the article_image tag, but haven’t figured out how to handle it – if at all – for the regular image/thumbnail tags. I’ll ponder. Any ideas on how to handle this sensibly would be gratefully received.

Currently:

<txp:article_image thumbnail="2" width="300" crop limit="1" />

will render your article image at 300px wide, with a crop=1×1 (read from config.php).

But:

<txp:images limit="1">
   <txp:thumbnail width="300" crop />
</txp:images>

will fail because valueless crop is not currently handled in those functions, so it passes an invalid crop ratio to SLIR. If you choose to use a crop (it’s optional) then you MUST specify a value for the image/thumbnail tags at the moment. That feels inconsistent.

In any case, you can alter the default values (primarily for admin-side usage) by adding something like:

define('TEXTPATTERN_THUMB_WIDTH', '320');
define('TEXTPATTERN_THUMB_HEIGHT', '480');
define('TEXTPATTERN_THUMB_CROPPING', '2x3');

to your config.php.

I’m not entirely sure why I chose 160px as default in core. Do you think that’s a bit miserly? If so, what size would be best to display automatic thumbnails on the Images panel as a fallback, in case an admin-theme hasn’t implemented its own prefs.json values?

phiw13 · 2026-01-06 07:38:04

Bloke wrote #342108:

[…] The question mark hangs over ‘crop’. If we don’t explicitly handle valueless crop, it will default to 1 if you don’t specify a value. Which is an invalid crop ratio, and your image will not be rendered. That feels buggy, so I’ve kludged it just now for the article_image tag, but haven’t figured out how to handle it – if at all – for the regular image/thumbnail tags. I’ll ponder. Any ideas on how to handle this sensibly would be gratefully received.

[…]

will fail because valueless crop is not currently handled in those functions, so it passes an invalid crop ratio to SLIR. If you choose to use a crop (it’s optional) then you MUST specify a value for the image/thumbnail tags at the moment. That feels inconsistent.

Thanks for explaining. I am not sure that is really useful, but I can see the need for a fallback in case the crop is inserted without value (accidentally deleted, or what…). Intuitively, that is not something a user would do, I think. Same as valueless width and height, it is not very intuitive.

I’m not entirely sure why I chose 160px as default in core. Do you think that’s a bit miserly? If so, what size would be best to display automatic thumbnails on the Images panel as a fallback, in case an admin-theme hasn’t implemented its own prefs.json values?

That seems a little small. 200px, or same values as you added to theme Hive, seems more appropriate. Small enough no to use too much space on the images list panel, large enough to allow user to see or recognise what is in the image.

I tried locally an article_image width valueless crop. It does what I think you wanted: crop to 1x1 (Sandspace leaves the aspect-ratio field blank). Adding define('TEXTPATTERN_THUMB_CROPPING', '4x3'); crops to that aspect ratio.

FWIW, I had the impression that thumbnail generation was a little slower in this case, but maybe that was just a case of localhost bad humor.

Bloke · 2026-01-06 10:34:25

phiw13 wrote #342109:

valueless width and height, it is not very intuitive.

True. But now, since it defaults to the more sensible least permissive output by default, it’s handy to have a way to say “use the native sizes please” if you really, really want them in the tags for placeholder / space reservation reasons.

Valueless attributes seemed sort of natural for this application, and saves having to manually look up or set the dimensions by hand for each image. You can just add width / height to your tag and it’ll output the right sizes, even if you switch to using a (custom) thumbnail.

I’m still thinking about ditching the public-side access to the config.php thumb size variables, but maybe the crop should remain. Or maybe hard-code it to 1×1 if you don’t specify a value yourself.

That seems a little small. 200px, or same values as you added to theme Hive, seems more appropriate.

200 it is.

Bloke · 2026-01-06 10:44:52

Incidentally, the database sizes will also be triggered if width='' or height=''. They mean the same as valueless BUT that has an interesting ramification:

<txp:article_image thumbnail width='<txp:variable name="my_width" />' />

will behave like this:

1. if my_width has a positive value, the thumb will be displayed at the designated size.
2. if my_width returns nothing, the thumb will be displayed at the database width value (either full size, or thumb size if it’s a custom thumbnail).
3. if my_width returns “0” the width attribute will not appear in the markup and you’ll get the image displayed at native resolution.

The upshot is, if you’re doing this kind of variable-in-attribute thing, ensure you test if the variable exists and has a value before plugging it into an (article_)image or thumbnail tag to avoid any surprises.

Bloke · 2026-01-06 13:01:18

I’ve tweaked the article_image tag output now so that empty image paths are silently skipped.

Also removed references to the config.php variables in the tags so if you specify a valueless crop, you will always get 1×1 square.

Happy to alter this if anyone can think of a better solution.

phiw13 · 2026-01-09 03:11:14

One test failure with a transparent .webp image: cropping. This currently fails, the image has a black background.

<txp:images id="79">
  <img src="<txp:image_url thumbnail  height="600" crop="9x16" />" alt="3 coloured circles, cropped" height="600">
</txp:images>

PHP 8.5, Textpattern dev. Test image: dev.l-c-n.com/_b/3circles-F.webp

This could be annoying for admin site thumbnails if the admin theme crops the image (e.g. Hive)

Bloke · 2026-01-09 07:41:51

Yeah I had a go at trying to debug that black background thing the other day and ended up scratching my head.

The purported fix has been incorporated into our code but it’s still serving black backgrounds on some (not all?!) transparent files.

At this point I have no idea why. If anyone has any clues or knows the GD library better, please throw some pointers my way.

franzl · 2026-01-15 15:52:02

Updated my installation. Works fine without any problems so far.
Thank you for your work. :)

Textpattern CMS support forum

#76 2026-01-05 01:16:00

Re: Feedback: Textpattern CMS 4.9.0 released

Bloke wrote #341937:

#77 2026-01-05 01:18:35

Re: Feedback: Textpattern CMS 4.9.0 released

Bloke wrote #342065:

#78 2026-01-05 04:29:32

Re: Feedback: Textpattern CMS 4.9.0 released

Bloke wrote #342083:

#79 2026-01-05 07:28:52

Re: Feedback: Textpattern CMS 4.9.0 released

Bloke wrote #342082:

#80 2026-01-05 16:15:42

Re: Feedback: Textpattern CMS 4.9.0 released

phiw13 wrote #342089:

#81 2026-01-05 16:35:17

Re: Feedback: Textpattern CMS 4.9.0 released

bici wrote #342096:

#82 2026-01-05 18:53:59

Re: Feedback: Textpattern CMS 4.9.0 released

Bloke wrote #342097:

#83 2026-01-06 00:52:08

Re: Feedback: Textpattern CMS 4.9.0 released

phiw13 wrote #342089:

#84 2026-01-06 07:38:04

Re: Feedback: Textpattern CMS 4.9.0 released

Bloke wrote #342108:

#85 2026-01-06 10:34:25

Re: Feedback: Textpattern CMS 4.9.0 released

phiw13 wrote #342109:

#86 2026-01-06 10:44:52

Re: Feedback: Textpattern CMS 4.9.0 released

#87 2026-01-06 13:01:18

Re: Feedback: Textpattern CMS 4.9.0 released

#88 2026-01-09 03:11:14

Re: Feedback: Textpattern CMS 4.9.0 released

#89 2026-01-09 07:41:51

Re: Feedback: Textpattern CMS 4.9.0 released

#90 2026-01-15 15:52:02

Re: Feedback: Textpattern CMS 4.9.0 released

Board footer