SVG images with thumbnail attribute

phiw13 · Today 12:01:22

s the valueless thumbnail attribute expected to be ignored or do “something” when the inserted image is a SVG file? I stumbled on this issue while looking at older articles.

XX is the ID of a freshly uploaded SVG.

<txp:image id="XX" thumbnail width="400" alt="some text" />

At the moment, (TXP 4.9.2-dev, PHP 8.5) this generates:

<img src="/images/XXt.svg" width="400" alt="some text">

That returns a 404. Note the t, pre 4.9, or custom thumbnail type reference to a thumbnail image on the file system.

Explicitly specifying thumbnail="2" does the expected thing.

Bloke · Today 12:16:53

Hmmm. I assume the image itself has its thumbnail column value as 1. A valueless thumbnail attribute just grabs the value from the database and uses that. So if you “last used” a custom thumb, when you subsequently upload an SVG it will wrongly assume you want a custom thumb for that too.

SVGs that are uploaded should probably be forced to “automatic” (2) in the database to prevent this happening. Even though the UI element for thumbnail type is never exposed, the tags rely on it.

I thought I did that, but maybe not. Will investigate, thank you.

phiw13 · Today 12:28:50

So if you “last used” a custom thumb, when you subsequently upload an SVG it will wrongly assume you want a custom thumb for that too.

I don’t think that is the case as we don’t use custom thumbs as a rule for recent uploads, but possibly the user viewed an (older) image with a custom type thumb prior to upload of the fresh batch of images. We don’t remember though.

Bloke · Today 12:37:04

Okay, cool. Either way, it makes no sense to have anything other than a 2 or a 0 in that column for SVGs, since they are always “automatic” and resized from the original. Zero will, however, not show a thumb in the Image list panel so I guess 2 is best. Will see what I can do.

Untested but you could probably get round this by not using the thumbnail attribute. Just a width/height. But that burdens the user with implementation details, so it’s not ideal, and it should “just work” with or without the attribute.

giz · Today 16:16:55

Bloke wrote #342663:

Untested but you could probably get round this by not using the thumbnail attribute. Just a width/height. But that burdens the user with implementation details, so it’s not ideal, and it should “just work” with or without the attribute.

I’ve been using a plain <txp:image /> for svgs without any drama.

bici · Today 16:22:53

giz wrote #342664:

I’ve been using a plain <txp:image /> for svgs without any drama.

clarification. your solution requires no W or H size? Do you have to pre-size the SVG to your desired dimensions?

Bloke · Today 17:09:37

giz wrote #342664:

I’ve been using a plain <txp:image /> for svgs without any drama.

Good to know it works as intended. In this case, the image tag uses the native width (assuming it’s specified in the SVG code) to render the image, as those will be the dimensions set in the DB when the image is uploaded. They act the same as if you had specified the width/height manually.

This issue only affects SVG files that use the valueless thumbnail attribute because (dynamic) thumbnails – which is essentially what SVG are by inference – must have at least one dimension supplied, and if the thumbnail type in the DB row is set to custom (for whatever reason), Txp will wrongly presume a ‘t’ file exists.

Vienuolis · Today 18:23:43

phiw13 wrote #342657:

<img src="/images/XXt.svg" width="400" alt="some text">...

I am a bit confused: what is the purpose of this “t” in SVG format? I tend to think that the “t” has no meaning for an SVG image.

Bloke · Today 18:35:38

That’s correct. The ‘t’ has no place here. It’s a sort-of bug that I’ll try and fix.

Textpattern CMS

Textpattern CMS support forum

#1 Today 12:01:22