PW 3.0.121 – Core updates and more

[ryan]

The RC1 version for our next master release is here. This post covers all the details and information about how you can help. We also look at a a new PageAction module added to ListerPro, and a couple of other new modules currently in development:

https://processwire.com/blog/posts/processwire-3.0.121-core-updates-and-more/

[Robin S]

The PageActionClearImageVariations module sounds very useful, thanks @ryan. I have a number of sites where I suspect I have a significant amount of wasted disk space due to orphaned image variations.

Trouble is that I don't think I would able to identify the orphaned variations from attributes such as width and height. What would be ideal would be if there was some way to identify orphaned variations based on whether they are called within any site code (template files or modules). Do you think there would be any way to accomplish that?

Another idea I had was to see if fileatime() could be used to check if a file has not been accessed in a long time (which would be configurable) but based on a quick test it seems that the last accessed time does not get updated when an image is loaded by a browser. Any other approaches that could be useful here?

[horst]

9 hours ago, Robin S said:

Trouble is that I don't think I would able to identify the orphaned variations from attributes such as width and height. What would be ideal would be if there was some way to identify orphaned variations based on whether they are called within any site code (template files or modules). Do you think there would be any way to accomplish that?

Difficulties in this approach maybe, that there are many chained variations are possible in the wild. Also the intermediate variations in chains never will be served to browsers, but need to stay, as removing them will raise unnecessary recreations.  

Maybe for image heavy sites it can be useful to define all used variations in a collection of (some sort of) selector strings and execute this in a sandboxed scope against a default image name (basename.jpg). Using the resulting variation name patterns as whitelist, for example. 

Regardind file-a-time, this may be error prone by using any sort of hosting, crons or maintenance scripts running on a server or in a hosting account. 

[ryan]

@Robin S I don't think there is any particular way to know sort of manual analysis (looking to see what you are currently using). I suppose a crawler or creative find() could be coded up to find all the image sizes currently used on a site, but that's maybe more time and trouble than potential benefit. Though you did just give me the idea that perhaps I could have this module perform a find() on fields like "body" to see if any <img> references to each variation exists, before it matches it. That would be relatively simple.

But I think where this tool comes in the most handy is when you are making a change to the dimensions in some Pageimage::size() calls, and you want to clear out the old variations that you know are no longer needed. For instance, I knew very clearly what image sizes I could clear out of the sites directory because I was aware of the dimension change I was making in the code. Of course, if it turns out that some automatically generated image variations were still being used, then PW would just re-create them. Where you'd have to be more careful is with manually-generated variations like custom crops or sizes in a CKEditor field. You can exclude these automatically by using the exclude suffix option, though I'd always recommend using the "dry run" option to see what it's going to delete, before you let it actually delete them. 

[Peter Knight]

@ryan

Can you clarify how those images options are accessed?

I've installed the Module, have the latest ListerPro etc but am not sure where this appears within the UI.