Feedback: Textpattern CMS 4.9.0 released

wet · 2026-01-01 15:39:49

Bloke wrote #342043:

Hmmm, hu (and by inference ihu) are drawn from the site’s docroot… And Txp (should) set it correctly for each virtual site.

Both are set to https://example.com/ when printed from an article on the public side, and into the Preview window on the admin side with tags enabled. Looks good.

I expect the fix is to change: […]

Applying your proposed changes at line #230 in /vendors/lencioni/SLIR/SLIRConfigDefaults.php results in this message returned instead of the thumb image:

‘Image does not exist: https://example.com//images/42.jpg’

I think the two trailing slashes after the web host name are unintentional and not helpful. Cutting the trailing slash in line #230 like so

self::$documentRoot = preg_replace('#/$#', '', ihu);

…causes the thumb ‘image’ to read ‘Image does not exist: https://example.com/images/42.jpg’. This doesn’t help either.

Unfortunately, this issue requires further consideration. Is there anything I can help with?

Bloke · 2026-01-01 17:59:30

wet wrote #342057:

‘Image does not exist: https://example.com/images/42.jpg’

Hmmm, thanks for trying it out. That’s (sort of) closer insofar as it’s using ihu now, but I’m not sure whether it needs the file path to create the thumb or the URL. I’ll need to trace it through somehow to figure out which it needs.

Maybe it does need a file path instead of URL, but it needs to be cognisant of your subdir structure beneath it. Clearly other parts of Txp understand this and are okay with it, so it’ll just be a case of finding which global is the one we need to tell SLIR about so it can resolve the path properly, instead of using the erroneous docroot value.

Maybe instead of changing self::$documentRoot = ihu, we change it to self::$documentRoot = $path_to_site (along with importing the global variable at the top of the function)? That assumes your images can be found at /var/www/virtual/wet/example.com/images…?

Last edited by Bloke (2026-01-01 18:01:25)

RedFox · 2026-01-02 17:11:36

First of all… best wishes for 2026 and big thanks to the developers for making version 4.9… :))

My first installation of 4.9 and populating the database with tables from a new website, but made with 4.8: no pages, no forms … !? Thanks in advance for any help.

SOLVED! Clicking on Textpattern > Themes > Pages and Forms did the trick … :)

Last edited by RedFox (2026-01-02 17:21:55)

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 · Yesterday 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 · Yesterday 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.

Textpattern CMS

Textpattern CMS support forum

#73 2026-01-01 15:39:49

Re: Feedback: Textpattern CMS 4.9.0 released

Bloke wrote #342043:

#74 2026-01-01 17:59:30

Re: Feedback: Textpattern CMS 4.9.0 released

wet wrote #342057:

#75 2026-01-02 17:11:36

Re: Feedback: Textpattern CMS 4.9.0 released

#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 Yesterday 00:52:08

Re: Feedback: Textpattern CMS 4.9.0 released

phiw13 wrote #342089:

#84 Yesterday 07:38:04

Re: Feedback: Textpattern CMS 4.9.0 released

Bloke wrote #342108:

Board footer