Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#31 2020-08-04 10:42:31

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

Re: Multiple image handling: profiles

Bloke wrote #325138:

Nice! An additional 79KB plus whatever baggage composer brings in.

Just composer installed the whole lot (Glide, Intervention Image and Flysystem) and the size is about 900kb. That gives us image editing tools, image caching and (via Flysystem) the ability to add and use adapters to write the final images directly to services such as Amazon S3 and Azure. Pretty impressive.

Offline

#32 2020-08-04 11:15:45

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

Re: Multiple image handling: profiles

That’s not a bad package indeed. This is sounding viable.


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

#33 2020-08-04 14:26:02

towndock
Member
From: Oriental, NC USA
Registered: 2007-04-06
Posts: 296
Website

Re: Multiple image handling: profiles

Bloke wrote #325090:

It’s far better for users to just drag an image – whatever the size (max file upload limits notwithstanding) – and have Txp automatically generate every image size that we – the designers – have decreed we require. So it makes us a max-res 1600px image, plus a 1280px, plus an 800px and a 300px image because we know that our design supports those sizes.

The fact we never use the “collosal” original is a small price to pay for the end-user convenience of just being able to throw pretty much any image at the CMS and have the designer (the person who has set up the image profiles and breakpoints and templates) handle everything on their behalf.

Yes. These two brief paragraphs nail it. Image confusion is the one consistent issue I have in handing sites over to customers. Having the above capability in 4.9 in a manor that’s easy to use would be huge for Textpattern.

Offline

#34 2020-08-04 14:43:34

Dragondz
Moderator
From: Algérie
Registered: 2005-06-12
Posts: 1,370
Website

Re: Multiple image handling: profiles

Hi,

if handling images is like described by Stef then it will be a huge improvment in simplicity for end users.

I am eager to see the first draft of that.

Cheers.

Offline

#35 2020-08-04 15:12:15

Vienuolis
Member
From: Vilnius, Lithuania
Registered: 2009-06-14
Posts: 231
Website

Re: Multiple image handling: profiles

philwareham wrote #325122:

  1. You upload an original image at whatever max size it was created at. No processing is done on that image

I do not know PHP GD module capabilities nor Tinify quantization technique, but its Panda drastically eliminates my PNG and JPEG overweight without compromising image quality — and thus with no options, no questions about desired image size. Panda offers free Tinify API for HTTP, PHP, Node.js, WordPress and other CMS.

Sometimes I check my new pictures by another similar online service called Cloudinary, although it optimizes images on webpage only.

(i.e. it stays at original dimensions/file size). That is your master image, for want of a better word.

  1. Textpattern then creates one or a number of different sizes of that image depending on what profiles you have set up (we can define some defaults as a starting point).

That is what I meant naming it default txp:image — not txp:thumbnail, and not an original full-size master image, thank you.

EDITED: I remembered Cloudinary, too.

Last edited by Vienuolis (2020-08-04 15:36:37)

Offline

#36 2020-08-04 15:40:09

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

Re: Multiple image handling: profiles

Vienuolis wrote #325146:

I do not know PHP GD module capabilities nor Tinify quantization technique, but its Panda drastically eliminates my PNG and JPEG overweight without compromising image quality

Image optimisation tools are a separate discussion in my opinion, and perfect for plugin territory, once we have the fundamental image processing and UX nailed down.

You simply run whatever optimisation tool you have signed up for over your images directory. Indeed, all the third-party integrations mentioned in the Tinify website are simple scripts to point the API at the right image directory of the CMS.

Offline

#37 2020-08-04 18:35:53

giz
Member
From: New Zealand
Registered: 2004-07-26
Posts: 190
Website

Re: Multiple image handling: profiles

Bloke wrote #325112:

Realistically, I wonder if there are any security implications of leaving /install lying around after the fact?

To the best of my knowledge once installed in the (say) images directory, the installer script is no longer needed unless the location of slir is changed. eg. my all-grid template has slir installed in the theme’s directory. I ran the installer script once on my Mac under MAMP, and then transferred the theme to the live server. I didn’t need to reinstall slir in its new location.

There’s mention of a config file so I wonder if that might give some clues. i.e. does it just create the dir structure you highlighted or does it do more?

Dunno. It does have quite a few options, but I must admit I’ve never bothered playing with them as the default settings have always been up to the task.

Hmmm, I can feel some experimentation coming on…

Gluck!

Offline

#38 2020-08-04 19:37:43

giz
Member
From: New Zealand
Registered: 2004-07-26
Posts: 190
Website

Re: Multiple image handling: profiles

Bloke wrote #325127:

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.

I’m the last person to ask how slir works ;-) but clients replace/change images all the time and everything behaves as it should. We don’t need to know what has happened to the old unused cached versions – they get deleted from the system by slir’s garbage collection routine.

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.

An image rotation option would be incredibly useful. Just because the image is right way up on your desktop is no guarantee that it’ll stay that way when uploaded into TXP.

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.

Thats how I think it works: here’s my MAMP test install:

  • slir-install/cache
    • rendered (these are image files, and have varied creation dates)
      • 69d777f01ce76fac77f8ce391f207283
      • 545c44e5ec5f72edd4584756e96d78c3
      • 0279790813f31aef0e154cab7bed0687
      • a11095f466f57e006a7573849c52cedc
    • request (these show up as aliases on my mac, and have the same creation date)
      • 20bf2ec0606bcaaccc7ddc8edbef2a58
      • 96cc4dca608c785e0e975f564d6a9437
      • 749a7a44fa24ada11c9b5c8fa5d9ae0e
      • 300926855770a5f6edd2b3b0bde6aa13
      • a35997bd99ddc5082b73b474bba7a786

Offline

#39 2020-08-04 19:51:38

giz
Member
From: New Zealand
Registered: 2004-07-26
Posts: 190
Website

Re: Multiple image handling: profiles

On a MAMP install, slir’s .htaccess directive (sometimes) needs these 2 lines to be commented out:

# Prevent other scripts from interfering with SLIR
php_value auto_prepend_file none
php_value auto_append_file none

Offline

#40 2020-08-05 05:42:57

Vienuolis
Member
From: Vilnius, Lithuania
Registered: 2009-06-14
Posts: 231
Website

Re: Multiple image handling: profiles

philwareham wrote #325147:

Image optimisation tools are a separate discussion in my opinion, and perfect for plugin territory

Why? The quantization is not a choice between weight and quality — it always remains in original quality, eliminating overweight only.

For an example: smd::thumbnail asks publisher for image quality (default 75%). Alternatively, the quantization retains full 100% quality always, asking nothing, and providing images even lighter than optimized to 75%.

I’d like Textpattern would always (not only by default) upload quantized images only, do not caring about its raw stuff. Further graphics manipulation leaving to SLIR and plugins.

Publishers, designers, and sysadmins would be grateful for such simplicity ant clarity of Textpattern. And visitors would love the maximum quality and speed of webpages, produced by Textpattern.

Last edited by Vienuolis (2020-08-05 08:24:35)

Offline

Board footer

Powered by FluxBB