Images and the file system layout from 4.9.0

giz · 2021-03-28 18:28:37

I know I’m repeating myself, but SLIR leaves the /images folder and the images tab alone.

Further you don’t need to set up your various image sizes before hand, as it is all handled on-demand via the code.

Bloke · 2021-03-28 18:46:25

I looked at SLIR. Wasn’t quite sure how to set it up so that flexible sizes could be generated by admins from the UI. It seems to need a set of sizes and transforms and returns the images.

Hooking it up to the front end tags would permit denial of service or file system flooding but if the generation was limited to logged-in users then it might work.

Also need to see how it plays with hard coded thumbs uploaded by users, and how it scales.

I suspect it will be impossible to import images en-masse using SLIR because the cache is internally managed. So you’d have to generate the sizes afterwards. That might make manual processes a little heavier.

I’ll give it a play in a separate branch and compare it to Intervention. Thanks for the nudge.

philwareham · 2021-03-28 19:45:37

SLIR is end of life. Even the author recommends Intervention Image-based alternatives (which is the library we are adopting). Also see github.com/ambroisemaupate/intervention-request.

However that is already provided by Glide (specifically Flysystem) that we’ve looked at too (another Intervention Image-based library), which IMO handles this at scale better.

Bloke · 2021-03-28 20:11:38

Ah yeah forgot about the state of SLIR dev. Okay scratch that.

giz · 2021-03-29 19:34:41

While I’m all for progress, I veer away from new and shiny software until it has advanced to a level where anyone can simply copy it into a directory and it works (and stays working¹).

SLIR won’t be end of life until it stops working. Maybe future changes to php will cause it to crap-out, but then it is in the same boat as everything else; if the software is useful, someone will patch it.

Bloke wrote #329552:

I looked at SLIR. Wasn’t quite sure how to set it up so that flexible sizes could be generated by admins from the UI. It seems to need a set of sizes and transforms and returns the images.

Hooking it up to the front end tags would permit denial of service or file system flooding but if the generation was limited to logged-in users then it might work.

Also need to see how it plays with hard coded thumbs uploaded by users, and how it scales.

I suspect it will be impossible to import images en-masse using SLIR because the cache is internally managed. So you’d have to generate the sizes afterwards. That might make manual processes a little heavier.

I’ll give it a play in a separate branch and compare it to Intervention. Thanks for the nudge.

It doesn’t need setting up after its installed; if you want to resize/crop an image, you supply the sizes to SLIR using the image’s url only when its needed.

Caching is automatic; active cached images are maintained, old/unused cached images are binned.

Not too sure what you mean by a hook-up to front-end tags / denial of service etc, or importing images en-masse… We appear to have completely different takes on how it might be used (or how any such tool could be useful in a Textpattern context).

User imports scores / thousands of new images into Textpattern. They change / replace a few hundred of the existing images. SLIR isn’t involved. Configuring sizes and crop ratios is the realm of the designer / developer, and to my mind has no place in the images tab – it belongs in the page templates and forms.

We can leave the whole art-direction / responsive image sizing groups / redundant image sizes / etc aspect out of the image tab entirely, and leave it for image originals (and a single optional thumbnail) only.

¹ I’ve used SLIR for 10 years on every website I’ve developed, some big, some small. I kid you not that it is the only! software I’ve used that has never skipped a beat, never required fixing, never required maintenance.

michaelkpate · 2021-03-29 20:47:27

giz wrote #329568:

Not too sure what you mean by a hook-up to front-end tags / denial of service etc, or importing images en-masse…

What steps will reproduce the problem?

Attacker selects a link of an image.

Attacker changes the set dimensions of the link so the script generates a
new image instead of using cache. Making a program that spam http links with random generated dimension numbers in the link can easily be done in any programming language.

Server runs out of resources/crashes/gets disabled by host etc!

source: Security problem, attacker can drain server resources.

Bloke · 2021-03-29 21:56:39

giz wrote #329568:

We appear to have completely different takes on how it might be used (or how any such tool could be useful in a Textpattern context).

Not at all. We’re on the same page. I think images should be created when they’re needed and cached, and…

if you want to resize/crop an image, you supply the sizes to SLIR using the image’s url only when its needed.

… this is the bit that concerns me. Because when it’s needed in this context is when someone visits the front-end website, right? So you fashion a tag to fetch an image or three (at varying sizes) and the system goes to fetch them. It says, oops, I’ve only found one so I’ll create the other two and cache them. Is that right, or have I misunderstood?

If that’s the case…

Not too sure what you mean by a hook-up to front-end tags / denial of service etc

… then (as michaelkpate states above) all it takes is a bot/user with a grudge to use the DOM or write a script to loop over image sizes from 1×1 to (e.g.) 1280×1280 and every size in between for every image it can find on disk and fashion URLs to ask for all those images. Suddenly, your cache explodes and you have a bajillion image files.

That’s the reason I’m thinking about configuration and restricting image creation to either admin-side actions or to use the front-end tags exactly like that but only permit creation for logged-in users. Reduces the attack surface. I have no idea how easy that’ll be to achieve, but it’s something I want to solve.

If SLIR or whatever equivalent tool (Glide, etc) doesn’t work like that and is not exposed to everyone, then everything’s fine.

importing images en-masse…

If it was as simple as dumping images in Txp’s /images directory that’d be wonderful. But if you’re importing images from another (e.g. WordPress) system and you’ve exported the content, you need to maintain the integrity of article->image mapping(s). And Txp uses IDs, which are not known until you add them to the database.

So my only notion was that, whatever file system layout we intend to use for images, would benefit from being deterministic outside Textpattern. So you can rename your images and assign them an ID as you loop over your about-to-be-imported articles and put those files in the appropriate location so that, when you upload the images as import the XML files containing article data into the database, your mapping is already set up. Your images are exactly where Txp expects them and it can go about its business without you needing to manually go through and drag them into the interface.

After that, sure, if there’s auto-thumb creation and caching and on-the-fly image size creation, that’s great. Doesn’t matter. It’s all handled. It’s that initial mapping I want to be deterministic and easy to generate by hand so we’re not hamstrung by a fiendishly complicated array of directory names and numbers.

Our current system of dropping all images and their thumbs into a single directory is simply not good enough. When you get past a few thousand, file systems start to struggle. Any need to back up your file system to dump it to a disk requires shell access – FTP is painful to wait for it to read a dir of 15K+ images – and not everyone on their hosts has the luxury of a shell.

Configuring sizes and crop ratios is the realm of the designer / developer, and to my mind has no place in the images tab – it belongs in the page templates and forms.

No argument here. Your template is where you design what you want. The system needs to build images on the fly to fit your design. You upload a single, high res image and that is never touched or altered in any way. BUT Txp needs:

1x image that we use to display on the Image Edit panel when you click to tinker with the metadata.
1x image in order to display a thumbnail/grid.

In both cases, using the full-size is too slow. So we need to hard-code another size. We’ve tentatively chosen 1920 × 1440 for the larger image and something like 240×240 for the grid. Still deciding.

If you view the image list/grid or click into the admin interface’s Edit panel, we can generate these on-the-fly via SLIR (or equivalent: in this case Intervention/Glide). But if you haven’t gone into the Edit panel – you’ve just uploaded the original and jumped to another panel – then we’d be forced to let some image auto-creation tool try and crunch down the sizes it needs from the original which may be 20MB and 8000 × 6000px resolution, or higher.

That’s not only going to hurt performance – even if it only has to do it once and cache all the smaller versions (unless the cache is flushed and it needs to do it again) – it’s a potential out-of-memory situation waiting to happen. It affects stability.

So, what we’re planning is that when you upload the original, we’re going to auto-create this working copy (for want of a better phrase) right then. Pass the original to whatever tool we choose to automatically make this image size so we know we have it cached. And then any future on-the-fly image creation can take place from this working copy. Much, much faster. Less chance of running out of memory when you view a gallery, for the price of a few extra seconds of wait time at upload.

If we can create both versions from the same in-memory copy using the library, great:

SomeLibrary::make('/path/to/massive_image')
    ->resize('1920x1440')
    ->save()
    ->resize('240x240')
    ->save();

That’d be ace. If it’s not possible to chain like that it might need to be done this way:

SomeLibrary::make('/path/to/massive_image')
    ->resize('1920x1440')
    ->save();
    SomeLibrary::make('/path/to/working_copy_just_created')
    ->resize('240x240')
    ->save();

We’ll lose a bit of quality but hey it’s only a thumbnail for use on the back-end. People’ll get over it. But if we can keep the quality up then there’s no reason people can’t use this 240×240 in their own grid on the front-end. And the working copy too as part of their super-responsive desktop experience. The cache is there: use it.

Any new images, auto-created as needed by the design, are generated from the working copy. The original is pristine; there just as a reference in case you ever want to go back and recreate a high quality working copy at a different resolution. Maybe to rebase your responsive images when a new display density device is released.

We can leave the whole art-direction / responsive image sizing groups / redundant image sizes / etc aspect out of the image tab entirely, and leave it for image originals (and a single optional thumbnail) only.

Sure, we could. But if the cached image has been made already by some auto-creation tool, why not acknowledge its existence in the back-end? Why not show people which ones have been created? If the cache is under some other system’s control – in your case, SLIR – then this is impractical. We have no idea how that cache is managed and auto-purged so we only know the definite location of original+working copy+grid thumb.

But, if the tool we choose allows us to dictate the cache location – and Intervention can do this, if we don’t defer caching to its optional Laravel component – then we have an opportunity to offer art direction and image manipulation on any of the auto-generated thumbs for free. Pick one to operate on and manually upload a better pic, or crop it, or recolour it, or whatever. If we choose to permit this. We might not.

By not auto-flushing the cache, you might get a few sizes left behind that aren’t used. The UI can show you how many sizes there are for any image and you can choose to delete the ones you don’t want right there from the interface. A multi-edit option could allow you to delete all images matching a particular size. If there are too many and you have command line access, go nuts and find | rm {} -\.

But if the file system can cope without grinding to a halt, leaving unused files around won’t hurt and you can tidy them up when you feel the need. If we leave the file system as it is today and start generating additional image sizes in the same directory – even in individual folders directly under /images – we are going to stress the server and slow down the site at some point in some applications. Not everyone, and it might only be a handful of sites, but it will affect them.

tl;dr: I’m totally with you on auto-generation. I just want to make sure that the tool we pick can grow and not hurt the performance we’ve strived hard to maintain when image-heavy sites reach 10-, 20-, 50-thousand images…

giz · 2021-03-30 00:23:29

Thanks; I’ve learnt a lot!

Wouldn’t it be possible to restrict calls to the script i.e. only accept urls generated from the site itself?

phiw13 · 2021-03-30 02:50:27

Bloke wrote #329575:

Lots of interesting thoughts, but this little tidbit worries me:

BUT Txp needs:

1x image that we use to display on the Image Edit panel when you click to tinker with the metadata.

1x image in order to display a thumbnail/grid.
In both cases, using the full-size is too slow. So we need to hard-code another size. We’ve tentatively chosen 1920 × 1440 for the larger image and something like 240×240 for the grid. Still deciding.

I do hope that at least the larger size image is configurable or optional (and just fetch / use the image the user has just uploaded).

landscape mode only, other types of images are cropped ? That does not work for me at all.
the size is larger than most images we ever upload
thumbnails: maybe a square cropped image can be used. For most sites I have worked, a grid of images is about completely useless based on the mockup Phil had posted once. More that the image, the meta data is important for us. Additionally, a square crop may cut too much valuable info out of the image for the thumb to be marginally useful.

colak · 2021-03-30 04:50:39

phiw13 wrote #329577:

Bloke wrote #329575:

thumbnails: More that the image, the meta data is important for us. Additionally, a square crop may cut too much valuable info out of the image for the thumb to be marginally useful.

+1 for that. I believe that the size and ratio of the thumbnails should be user specified. Similar to how it is now. If it means having an aesthetically pre-defined grid of containers rather than photos, be it.

Bloke · 2021-03-30 06:44:29

phiw13 wrote #329577:

I do hope that at least the larger size image is configurable or optional

Not optional if you upload a larger image, no. We need a baseline. If you upload a file of exactly those dimensions, there’s no need to create a working copy. Presumably we’d just clone it (though that does seem a waste of disk space). Will think about it. Photos won’t be upscaled in any case. Intervention can limit that easily.

landscape mode only, other types of images are cropped ?

Nope. If you upload portait, the dimensions are flipped. And if you upload square, the longest (? shortest?) dimension will be used. I’ve deliberately avoided “width” and “height” terminology, favouring “dimensions” instead for the reason that specifying 800×600 is interchangeable based on the incoming aspect ratio.

the size is larger than most images we ever upload

That’s why I said tentative. We need a tradeoff between quality and size that doesn’t degrade if other images are generated from it. Undecided right now. That may be too be big. Unsure.

In any case, I’m planning to have these sizes configurable in a hidden pref. Preset to the sizes above at shipping.

thumbnails: maybe a square cropped image can be used.

No idea how it would work. Cropped might cut too much. Rescaled may be too tiny to be of use. I’m open to ideas here. In any case, if we expose all the sizes you can choose your own thumb. And if you don’t like the grid, there’s always list view :)

Last edited by Bloke (2021-03-30 11:08:42)

philwareham · 2021-03-30 07:39:59

SLIR won’t be end of life until it stops working.

As far as I’m aware, SLIR doesn’t work on at least PHP 8, possibly PHP 7.4 too. Glide does essentially the same as SLIR plus a whole lot more besides.

Not wanting to slate SLIR, but the author has publicly said he doesn’t intend to work on the project anymore. Of course, we could fork it ourselves and fix but with other, better libraries available this seems folly.

Textpattern CMS

Textpattern CMS support forum

#37 2021-03-28 18:28:37

Re: Images and the file system layout from 4.9.0

#38 2021-03-28 18:46:25

Re: Images and the file system layout from 4.9.0

#39 2021-03-28 19:45:37

Re: Images and the file system layout from 4.9.0

#40 2021-03-28 20:11:38

Re: Images and the file system layout from 4.9.0

#41 2021-03-29 19:34:41

Re: Images and the file system layout from 4.9.0

Bloke wrote #329552:

#42 2021-03-29 20:47:27

Re: Images and the file system layout from 4.9.0

giz wrote #329568:

#43 2021-03-29 21:56:39

Re: Images and the file system layout from 4.9.0

giz wrote #329568:

#44 2021-03-30 00:23:29

Re: Images and the file system layout from 4.9.0

#45 2021-03-30 02:50:27

Re: Images and the file system layout from 4.9.0

Bloke wrote #329575:

#46 2021-03-30 04:50:39

Re: Images and the file system layout from 4.9.0

phiw13 wrote #329577:

#47 2021-03-30 06:44:29

Re: Images and the file system layout from 4.9.0

phiw13 wrote #329577:

#48 2021-03-30 07:39:59

Re: Images and the file system layout from 4.9.0

Board footer