Clear way to ifentify default image variation thumbnail ?

[happywire]

On my quest/journey to get responsive images sorted and given in at least my workflow I have no use for the default image thumbnail created by ProcessWire I am wondering the following.

What clear ways are there to identify this default image variation/thumbnail?

Can I assume that this default image thumbnail will always have a "0x260" or "260x0" string in the filename?

In what cases would the default thumbnail not have that exact string in the filename?

I guess one case would be when $config->adminThumbOptions has been changed by the dev/user.
If this is the case, how could I check if $config->adminThumbOptions has been changed and then carter for that change?

I am asking since I am trying to create a workflow that might not only work for me but could also work for others.
Hence I am wondering if I should try to catch such changes to $config->adminThumbOptions or rather just follow my own route and not worry about $config->adminThumbOptions being changed.

In a way I would love to make a working module while also allowing devs to change default $config->adminThumbOptions.
On the other hand I know, at least for now I have no reason to edit $config->adminThumbOptions and hence will know that the default variation will always have a "0x260" or "260x0" string in the filename.

Ideally it would be best if this default image thumbnail could somehow be identified/tagged/have an additional key added in the $image array/whatever so that I can single it out without having to delete it, as, that is not possible at all.

[LostKobrakai]

I'm wondering why you need to identify the default variation in the first place? Only use the sizes you generated and you should be fine and it won't break whenever any other functionality generates other sizes. It's not just the default variation created for the image inputfield, which might generate extra variations.

[happywire]

46 minutes ago, LostKobrakai said:

I'm wondering why you need to identify the default variation in the first place?

I have my "variations" created externally and do not want to mix them with ProcessWire variations or create them them with ProcessWire.
The only thing I need is the original images uploaded via admin panel.
Everything else is done outside ProcessWire and then stored in the assets folder for the page.

46 minutes ago, LostKobrakai said:

It's not just the default variation created for the image inputfield, which might generate extra variations.

Oh, good to know! What else might create extra variations?

Comes to mind, could it be that such "other variations" overwrite or rename already existing, externally created variations, for any reason?

Just tried to add my variations to a folder inside the assets folder for the page but images from there are not being served.
Hmm.. No clear way to keep things apart, plus having to deal with "possible arbitrary variations" that "might" be created.

Edited March 29, 2019 by happywire
added more info

[Autofahrn]

Instead of figuring out which variations may be added from functionality inside PW, why don't you simply place your variations into a subdirectory of the asset path (/site/assets/files/1234/happyvariations)?

To enumerate those variations you do not go through $image->getVariations() but use the contents of that subdirectory? Of course you do not get an array of images but only the filenames. That way you may even encode other information into the filename and retrieve those information using preg_match. Depending on your use case this may even be a time-saver since the image files do not need to be opened.

Of course you do not see those "private" variants in the admin and need to manage them completely from your scripts.

[happywire]

@Autofahrn Exactly what I am trying to do, create a custom array of my variants of images with the keys and values I want, perfect!
Happy to do all the globbing, sorting, pushing, etc. myself. Nice!

Though last bit, site/assets/files/1016/custom/something-nice.jpg shows me a 404.
Argh.. hang on, had a typo in the URL! They ARE being served!
Oh wow, super nice, again, if only I had known this before!
??

Maybe I have not looked good enough, does it mention anywhere in the docs/blogs/forums that

a) anything you place inside the assets folder for a page with a particular nomenclature gets served?

b) anything you place inside a custom folder and is abiding to a particular nomenclature inside the assets folder for a page  gets served?

Bottom line, this new info is a huge relief and if I take it far, with a custom admin page and some extra coding I might even be able to create my version of handling images including a preview in the admin panel with ProcessWire.. liking this!

[Autofahrn]

11 minutes ago, happywire said:

does it mention anywhere in the docs/blogs/forums that

probably not, since any file placed into your webspace will be served directly, they do not need to follow any particular nomenclature -  that's just files. Happens also to any .js and .css files buried somewhere in a module's folder, for example.

11 minutes ago, happywire said:

with a custom admin page and some extra coding I might even be able to create my version of handling images including a preview in the admin panel with ProcessWire

Before implementing admin pages for this purpose, why not simply extending InputfieldImage? You may use ImageExtra as a starting point...

[szabesz]

6 hours ago, happywire said:

a) anything you place inside the assets folder for a page with a particular nomenclature gets served?

b) anything you place inside a custom folder and is abiding to a particular nomenclature inside the assets folder for a page  gets served?

The relevant rules are explained in .htaccess: https://github.com/processwire/processwire/blob/master/htaccess.txt#L145

I recommend keeping these rules and pick a location which is not protected bye the default .htaccess file.

[LostKobrakai]

19 hours ago, happywire said:

Oh, good to know! What else might create extra variations?

There‘s no fixed list of things creating variations. You might install a new module, which creates ones or you setup the admin theme to use images as avatars, which might use a different size to the image inputfield preview. An update to processwire might change the dimensions of variantions used (even though Ryan is quite careful with those changes).

[happywire]

On 3/29/2019 at 8:27 PM, szabesz said:

The relevant rules are explained in .htaccess: https://github.com/processwire/processwire/blob/master/htaccess.txt#L145

I recommend keeping these rules and pick a location which is not protected bye the default .htaccess file.

Incredibly useful resource, thank you!

[happywire]

On 3/30/2019 at 8:30 AM, LostKobrakai said:

There‘s no fixed list of things creating variations. You might install a new module, which creates ones or you setup the admin theme to use images as avatars, which might use a different size to the image inputfield preview. An update to processwire might change the dimensions of variantions used (even though Ryan is quite careful with those changes).

This means that if I have a src size of 1024px width in my responsive images array and somewhere down the line during work on a site I install a module "xyz" that also does, for any reason, create a 1024px wide variation of the original those might get mixed up or worst case overwritten?

So work starts, original.jpg -> original.1024x0.jpg is created.
Later during further dev of the site module "xyz" is installed and it also, for any reason that also might not be documented in the module docs, wants to create a 1024x0 variation.

Will ProcessWire overwrite the variation created first?

Or would the ProcessWire internal code make sure to see "ah, module xyz is installed and it wants to create a variation, but there is already a variation with that filename and 1024x0, so better not touch it!"

The implications would be that in the end the responsive image array I want to work with would be mixed up/diluted/changed/affected by images that I did not intend to be used, for any reason.
So this really means I have to come up with a way to strictly separate the ProcessWire image workflow from the responsive images array?

Or are people just fine with "ok, Ill upload this, whatever happens in the assets folders I don't care, I will just write a responsive image function that refers to those images and their variations, it should be ok.."

Perhaps because I am new to ProcessWire it has not "clicked" with me how one can have a tidy/clean/solid way of i.e. producing this responsive image syntax below while also being sure that the images created for it will never be touched/affected/overwritten/changed by either ProcessWire or any future module for any reason.

<picture>
	<source
		sizes="(min-width: 640px) 60vw, 100vw"
		srcset="image.200x0.webp 200w,
				image.400x0.webp 400w,
				image.800x0.webp 800w,
				image.1200x0.webp 1200w,
				image.1600x0.webp 1600w,
				image.2000x0.webp 2000w"
		type="image/webp">
	<img
		src="image.400x0.jpg" alt="A rubber duck"
		sizes="(min-width: 640px) 60vw, 100vw"
		srcset="image.200x0.jpg 200w,
				image.400x0.jpg 400w,
				image.800x0.jpg 800w,
				image.1200x0.jpg 1200w,
				image.1600x0.jpg 1600w,
				image.2000x0.jpg 2000w">
</picture>

 

[horst]

The imagesizer engines act as follows:

If "something" requires a variation of an image, it checks if this variation already exist in filesystem and, if yes: deliveres the cached version, and if no: creates it before delivering.

So, it doesn't matter if you install or uninstall modules or do api calls or what else. It is the simple rule: is it already there, serve it. Is it not there, create it and then serve it.

If you need to overwrite already existing images, you can pass the param "forceNew" => true in the options array to any of the pageimage size methods. Or you call the method removeVariations() on the original to delete ALL existing variations at once. (Maybe sometimes useful during development with images).

This all is handled internally by processwire when you work with pageimages and its sizing methods. If you want to do something besides that, maybe creating your own variations outside of processwire and you don't want them to be get touched / controlled by PW, then you should not use the pageimages naming conventions. But you will loose a lot of comfort then.

So, pageimages are basically all the images you added to PW using an image field attached to a page.

[happywire]

@horst Thank you. In theory or simple pseudo code, or if you can just talk me through the process, how would you go about obtaining the responsive image syntax above?

a) from a given set list of sizes between 120px width and 2560px width create the srcset array that checks existing variations for an image without mixing default variations or variations created by modules with it

b) make sure no variations that do not exist for an image are included in the srcset array, so an image that has a max width of 1200px does not have a srcset item of 2000px width in the syntax, meaning don't just have a fixed syntax for each image but really make the syntax from the image and its variations

At the moment I am still searching for a solution to this.. and to be honest I feel rather bad about this, asking so many questions, thinking I am the only one in the forums that seems to have trouble coming up with a decent responsive image workflow that results in the given responsive image syntax above..

[horst]