mplavala Surprisingly, this also happens for quite few other images you have there. I would overlook if this happened to small icons due to some overhead, but beats me why this is the case for files in assets/images/temp. There is probably something fishy going on wit how you server handles the conversion to WebP, or you original images already are highly optimized, probably by reducing the quality when they were created.
Agreed. The original images are highly optimised to start with, correct, via quality reduction to reduce file size (it's a balance between quality and loading time). Some webp conversions are definitely significantly smaller still though and I can notice a difference in page loading for those pages with the smaller webp converted images that are working direct from the template - it's really nice.
mplavala Also, we can automate this by displaying smaller of the two images without manual intervention. Adding a ticket.
Wow, wow, wow! That would be incredible. and so smart. Love the sound of this. Thank you so much.
mplavala But some mechanism for manually excluding images will also be implemented.
Fantastic, thank you kindly.
mplavala No, everything looks just about right.
Great. Thanks for checking.
mplavala Yes, this can help and at least give me more info (whether the plugin re-creates the WebP images or not), so maybe go ahead and delete assets/cache/webp.
Roger that, I deleted the assets/cache/webp folder and also the /assets/cache/images/temp folder.
Things were looking good... the social icons in the header (which is from a DocLister menu) started showing as webp images again - and the top level [+image+] in my slideshow DocLister row template was converted to webp = nice.
Then I tweaked the srcset in my slideshow DocLister row template per below - as soon as I did that, the social icons in the header reverted back to .png (all DocLister menus stopped outputting webp at this point).
The only way to get the webp images back (talking non srcset images here only) was to redelete the assets/cache/webp and /assets/cache/images/temp folders.
So it seems that anytime I ask webpBackground to work in srcset like below (tried different apostraphe combos, not change fyi), webp totally stops working for me in all DocLister row templates.
[!webpBackground? &src='[[phpthumb? &input=`[+image+]` &options=`w=1800,q=90`]]'!] 1800w,
[!webpBackground? &src='[[phpthumb? &input='[+image+]' &options='w=1600,q=90']]'!] 1600w,
[!webpBackground? &src=`[[phpthumb? &input=`[+image+]` &options=`w=1400,q=90`]]`!] 1400w,
[!webpBackground? &src=`[[phpthumb? &input=`[+image+]` &options=`w=1200,q=90`]]`!] 1200w,
[[phpthumb? &input=`[+image+]` &options=`w=1000,q=90`]] 1000w,
[[phpthumb? &input=`[+image+]` &options=`w=800,q=90`]] 800w,
[[phpthumb? &input=`[+image+]` &options=`w=650,q=90`]] 650w,
[[phpthumb? &input=`[+image+]` &options=`w=480,q=90`]] 480w,
[[phpthumb? &input=`[+image+]` &options=`w=300,q=90`]] 300w"
Could each webpBackground do with a unique id like a DocLister call eg &id=
Perhaps I should just keep webpBackground srcset calls out of the DocLister row templates but I am holding out hope that I can get it working because the potential on all images is great 🙂
In the assets/cache root folder I can see 3 phpThumb .txt files per below. I have not seen these before in any other site. Not sure if that could have any bearing on my webpconverter issues in DocLister row templates?
Version: ImageMagick 6.9.10-68 Q16 x86_64 2021-01-06 https://imagemagick.org
Copyright: © 1999-2019 ImageMagick Studio LLC
Features: Cipher DPC Modules OpenMP(3.1)
Delegates (built-in): bzlib cairo fontconfig freetype gslib jng jp2 jpeg lcms ltdl lzma openexr pangocairo png ps rsvg tiff wmf x xml zlib
Thanks again for great help and suggestions. Have a super day 🙂