Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#21 2020-08-04 09:32:38

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 2,116
Website

Re: Multiple image handling: profiles

Bloke wrote #325120:

Not at all. Sorry if that came across. It was late and my brain couldn’t face coming up with more than one (simple) example, so I chose gallery.

[…]

Does that give you more insight into the idea?

That explanation definitively gives more insight into the concept. It does indeed offer some possibilities (ok… more than just some).

Code wise, for most use cases, <img src="" srcset="" sizes=""> ought to be sufficient. And, as now, <txp:images /> could still be used as a container tag to manually build the needed construct (thinking the use of <picture /> to have dedicated light and dark mode images e.g. screenshots of software UI).


Where is that emoji for a solar powered submarine when you need it ?

Offline

#22 2020-08-04 09:34:51

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 9,723
Website

Re: Multiple image handling: profiles

philwareham wrote #325122:

You upload an original image at whatever max size it was created at.

Yes, absolutely. One main, full size image. No thumbnails, no nothing else. Whether this image is physically stored in a single /images dir (as today) or we put some algorithm in place to spread the load is a decision for later.

Textpattern then creates one or a number of different sizes of that image depending on what profiles you have set up

This is where my thinking has skewed away from profiles. After looking more at slir (and maybe there are other similar projects out there) I’m of the opinion that on-demand thumbnail generation really is a much better solution… sort of.

When you upload the original and (today’s) Images panel refreshes its list view, it could encounter an <img> tag that says “go grab this image at 150px square”. It would do so. It would generate one right then at that size. Cache it. Next time you refresh the page, boom, it’s there immediately. And also available at that size if anybody wants to use it in front-end land.

If, however, you were in grid view, core could say “go grab the image at 450px square, crop it and pad it with light grey to fit” (just an example, we might not bother with padding backgrounds and use CSS for that). It would do so, generate it cache it, done. Same for every image in the panel. And, likewise, if anybody in front-end land crafts a tag that requires an image at that size with that colour background, it’s already available in the cache.

Yes, potentially, it will create a lot of images if you have multiple background colours and stuff like that on your site, for the images on each of your pages. But the point is, it’s only creating ones you’ve used. Not ones that don’t make sense or have no business being created (e.g. upscaled large images from tiny icons).

We could craft it so the Images panel requests 450px square AND 900px square images as its own srcset so the <img> tag could use the second for double-density displays. Then we get retina support on the admin side out of the box. Heck, we could even set the default sizes we use on the admin side as a (hidden/advanced/config.php) variable or pref. Then if someone wanted to make different size images for their quad-density super crunjo display, well, go for it. Edit the pref or override the values and next time you visit the admin panel, it automatically rebuilds your thumbs in the size specified for the current device being used.

Dunno. Just freewheeling.

Possibly, user can upload replacement images for any that have been auto-created by the profile.

Now this is where slir falls down. Unless we can understand how it caches images and retrieve them, we have no idea how many images at varying sizes and crops and whatever have been created. So we can’t offer to individually replace them.

That is a bind. If, as you say, you want a different thumbnail for some specific reason, you’re out of luck. I wonder if we could have a parallel system that acts like today so if you have specific reasons for uploading an image of a particular dimension or whatever, you can do so and it goes into our regular Txp /images cache as it does today with a suffix (or in a subdir). Then there’s nothing to stop us offering a way in the tags to say “I know what I’m doing, use my image and not the auto-generated one, please.”

Dunno.

Another unknown, given the age of the code, is if slir supports WebP or any other new format. I suspect not. So as the formats grow in popularity and the VHS-Betamax wars eventually resolve themselves, we may need to patch the code to support them. We need to patch Txp anyway as it can’t handle anything beyond the main three formats.

Cropping/rotating/etc of original file can be done directly within Textpattern panel, but the edited file never overwrites the original.

Again, this is something slir doesn’t give us. So if you upload an image that is on its side from the camera, I don’t know how to handle this. If we’re saying we’re not changing the original in any way once it’s uploaded, this is going to be an issue.

Now, if we were to alter the image and allow some rudimentary editing of the original so you could zoom in, crop, rotate inside Txp and then commit your modifications, how does that affect any cached images that have already been created? Presumably they have no knowledge of the fact you’ve changed it, so when you ask for your 450px version, you get the old one from the cache. Gary might be able to supply some info on this if he’s ever replaced any original pics from the Image Edit panel.

If slir is clever, it will check the timestamp of the original and if it differs from that of the cache, it’ll invalidate the cache version and overwrite it with a fresh copy generated from the (changed) original. If it does that, I’d be happy with just allowing people to edit the original and have it cascade to the image cache on an as-needed basis.

I need to play with my latest local WordPress install too and see if there is any learning we can get from their process.

That’d be ace, thanks. Anything we can learn from and do better works for me.

If we can’t solve the ‘individual replace a thumb’ issue mentioned above, then we may need to use hard-coded profiles, or come up with some way to query the current cache for “all the images that have been created from this original”. At least we could then display them on the Image edit panel so they can be manipulated individually, perhaps.

Last edited by Bloke (2020-08-04 09:58:18)


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

#23 2020-08-04 09:57:26

philwareham
Core designer
From: Haslemere, Surrey, UK
Registered: 2009-06-11
Posts: 3,363
Website

Re: Multiple image handling: profiles

Erm, you know Pete has already suggested a modern, supported alternative to SLIR which does much more besides (and can use both/either ImageMagick and GD)? Please see github.com/textpattern/textpattern/issues/1472.

I agree that if the profiles thing can be automated via something like the above, then that is way simpler for the user. Also, I’m not totally wedded to not being able to crop/edit the original – as long as users are aware that the process is destructive.

Offline

#24 2020-08-04 09:59:20

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 9,723
Website

Re: Multiple image handling: profiles

philwareham wrote #325129:

Erm, you know Pete has already suggested a modern, supported alternative to SLIR which does much more besides

Jeez, my Swiss-cheese brain. Okay, right. I’m going to get in my box now and shut up.

EDIT: I seem to recall when I looked at it that it was Laravel-heavy so maybe it has a large byte count. Not sure.

EDIT 2: Seems to be 250KBish unpacked out of the box, which for all that functionality is remarkable if that truly is the extent of it. I suspect when running composer require it’ll pull in a tonne of library code from elsewhere… maybe? But if 250KB is all there is to it, then maybe we can use this. Perhaps wrap an interface around it to create images on the fly in a manner similar to the way slir does when we craft certain image-ish URLs in core code or via our <txp:image*> tag suite.

Last edited by Bloke (2020-08-04 10:14:21)


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

#25 2020-08-04 10:00:25

gaekwad
Admin
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 3,131

Re: Multiple image handling: profiles

No harm, no foul.

Offline

#26 2020-08-04 10:13:10

philwareham
Core designer
From: Haslemere, Surrey, UK
Registered: 2009-06-11
Posts: 3,363
Website

Re: Multiple image handling: profiles

Image Intervention has optional support for Laravel, but the base library is 102kb zipped. Considering what it does I think that is not too bad. The caching module add-on (Intervention Request) is about 77kb zipped.

EDIT: I’ve just loaded Image Intervention with composer and it’s looking around 475kb total with additional libraries. Intervention Request caching add-on requires Symfony though, so that one is massive and unfeasible. So maybe just the Image Intervention alone.

Offline

#27 2020-08-04 10:14:03

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 9,723
Website

Re: Multiple image handling: profiles

Yeah, I just unpacked it as you were typing – see my edit above.


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

#28 2020-08-04 10:18:19

gaekwad
Admin
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 3,131

Re: Multiple image handling: profiles

See also github.com/thephpleague/glide – powered by Image Intervention, framework-agnostic.

Offline

#29 2020-08-04 10:24:07

philwareham
Core designer
From: Haslemere, Surrey, UK
Registered: 2009-06-11
Posts: 3,363
Website

Re: Multiple image handling: profiles

Nice, let’s get the CSP issue ticked off and I’ll help where I can with implementing a test of Image Intervention (should have some time next week).

Offline

#30 2020-08-04 10:29:23

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 9,723
Website

Re: Multiple image handling: profiles

gaekwad wrote #325135:

See also github.com/thephpleague/glide – powered by Image Intervention, framework-agnostic.

Nice! An additional 79KB plus whatever baggage composer brings in. I like that Glide can sign image requests, for security. That’s neat.


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

Board footer

Powered by FluxBB