Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Handling multiple image formats
What about having two different plugins then? That would solve the problem beeing stuck in which direction to go and sounds like a good compromise to me.
So the photoblogger that needs some image manipulation within txp could get that through a plugin. And the person that needs a bit more sophisticated image handling would get that also through the help of a plugin. If both is needed, you can get both.
I can imagine that there are also people that are neither interested in cropping and flipping their images nor do they have the need to have multiple sizes or cached files of their images.
Delivering different sizes and different file formats should perhaps be the standard way to go due to the development of the web and devices. But wouldn´t it be relatively easy to include that into txp as a standard ones it has turned out it is really needed and everybody is using it anyway? Would maybe a poll make sense to find out more about this?
I don’t want people to have to define anything up front, but it’s necessary to prevent abuse. Whatever tool we decide upon to deliver on-the-fly image creation needs to be limited to only produce select sizes.
That makes sense. I am not sure if or how slir was preventing that and if this could be copied. But restricting the sizes by predefined sizes in txp sounds like a good idea.
Annoyingly, it might be nice to constrain just one of the dimensions, e.g. specify a max width of 320px. But that would mean people could spam the other dimension with everything from 1px to 50000px, and tie up the server. So I think the only sensible/safe way is to constrain what image sizes can be constructed in both dimensions.
It is true that it would make things easier but I guess it would also work without having to define both dimensions.
If it turns out it is the way to go, wouldn´t you incorporate caching-images-by-url into the <txp:image/> tag anyway? And if you do so wouldn´t it be possible to have some kind of unique key that goes with it that allows image-generation-by-url only to fire when started from an <txp:image/> tag and not just from “outside” by calling a url? That would make the security concerns obsolete. Right?
Last edited by demoncleaner (2023-05-07 05:11:39)
Offline
Re: Handling multiple image formats
demoncleaner wrote #335414:
If it turns out it is the way to go, wouldn´t you incorporate caching-images-by-url into the <txp:image/> tag anyway?
Absolutely.
wouldn´t it be possible to have some kind of unique key that goes with it that allows image-generation-by-url only to fire when started from an <txp:image/> tag and not just from “outside” by calling a url?
Nice idea. That would work for the public site if SLIR or our tool of choice accepts it. But I think it just dutifully echoes out whatever it is given. Giz mentioned a config file that restricts what sizes it can output so that might be our only route.
It probably wouldn’t help on the admin side either. But we have more control there, so more options.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline