WebP Converter - plugin to convert images to WebP

nick0

Moving from https://forum.evo.im/d/14-what-are-your-default-extras/43

mplavala Try reinstalling the plugin. If even standard images are not converted, then the plugin is either disabled, or maybe someone deleted the assets/plugins/webpconverter/ folder with the PHP code.

Thanks for the advice. Have reinstalled webpconverter a number of times in between testing = no change. Cache cleared copious times = no change.
In Elements I deleted the snippet and plugin, on the server I deleted the webp... plugin folder. Then reinstalled and cleared cache = no change.

On the server:

assets/plugins/webpconverter/ exists with one 4.3kb file inside called plugin.webpconverter.php
confirming there is no webpconverter folder in assets/snippets/ - but there is a snippet callled webpBackground in Elements > Snippets
Does that setup look right?

In my slideshow example, the row template (with If calls pulled out in case that was related = that had no change) looks like so:

<div class="slider" data-title="[+title+]" data-cycle-desc="[+bannertxt+]">
	<a href="[~[+id+]~]"><img src="[+image+]"
		srcset="
			[!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, 
			[!webpBackground? &src=`[[phpthumb? &input=`[+image+]` &options=`w=1000,q=90`]]`!] 1000w, 
			[!webpBackground? &src=`[[phpthumb? &input=`[+image+]` &options=`w=800,q=90`]]`!] 800w, 
			[!webpBackground? &src=`[[phpthumb? &input=`[+image+]` &options=`w=650,q=90`]]`!] 650w, 
			[!webpBackground? &src=`[[phpthumb? &input=`[+image+]` &options=`w=480,q=90`]]`!] 480w, 
			[!webpBackground? &src=`[[phpthumb? &input=`[+image+]` &options=`w=300,q=90`]]`!] 300w"
		sizes="100vw"
 		alt="slideshow image" /></a>
</div>

The row in the front end source looks like so with just jpgs:

<div class="slider" data-title="Page 2" data-cycle-desc="">
	<a href="page-2"><img src="assets/images/temp/photo-1200-2.jpg" srcset="
			assets/cache/images/temp/photo-1200-2-1800x-594.jpg 1800w, 
			assets/cache/images/temp/photo-1200-2-1600x-d85.jpg 1600w, 
			assets/cache/images/temp/photo-1200-2-1400x-88a.jpg 1400w,
			assets/cache/images/temp/photo-1200-2-1200x-983.jpg 1200w, 
			assets/cache/images/temp/photo-1200-2-1000x-996.jpg 1000w, 
			assets/cache/images/temp/photo-1200-2-800x-f0b.jpg 800w, 
			assets/cache/images/temp/photo-1200-2-650x-cb2.jpg 650w, 
			assets/cache/images/temp/photo-1200-2-480x-518.jpg 480w, 
			assets/cache/images/temp/photo-1200-2-300x-96f.jpg 300w" sizes="100vw" alt="slideshow image"></a>
</div>

Any other ideas? Would love to get this working.

Confirming that webp still works directly in a chunk (eg using [*banner*]).

mplavala Finally, if none of the above, then check whether the PHP functions mime_content_type and imagewebp are available at your hosting. The plugin needs those functions to work properly. But if it worked before, then they likely are available.

Hmmm... Not sure where to change those settings in cPanel. I can't see them in Select PHP Version (php was 7.2 but now 7.4, no change). If webp still works directly in a chunk using [*banner*], wouldn't these settings be the same for DocLister calls using [+image+]? I am stumped

mplavala Next month, I will add a thing so that if the functions are missing, the plugin will create an error message in the log.

Nice!

nick0

Moving from https://forum.evo.im/d/14-what-are-your-default-extras/45

mplavala Yes, that looks right.

Great 😃 . Thanks for confirming.

mplavala Yes, if webp works somwhere, then this is not the case.

Excellent. I'm on the right treack / halfway there then 😄 .

mplavala Try this:
[!webpBackground? &src='[[phpthumb? &input='[+image+]' &options='w=1800,q=90']]' !]
Also refresh the page few times. With phpthumb, it sometimes happens that webpconverter thinks that the webp image is too old and hence is not displayed. Once phpthumb generates the image and you wait few seconds, this fixes everything because then the phpthumb image isn't "new" anymore.

Thanks for the advice, much appreciated. I tried the single quote options and variations like below with about 10 "keyboard shift and browser reloads" with Evo Cache Clearing in between. No change, I still can't get it to work in my 1.4.14 demo site that I am testing it in and occasionally get the gremlin in again that displays all the raw snippet calls in the front end rather than expected output.

[!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,

The images are already generated in phpthumb, they're not new pics so presumably already created and cached?? PHPThumb is version 1.3.3.

I managed to get rid of the raw snippet calls in the front end by undoing one of the srcset lines but still at square one with the row templates. Bummer. This plugin looks so good. Not sure what to try to get it working now. Any other suggestions greatly appreciated.

nick0

mplavala So I made sure the snippet works on my sites and it does. Honestly, I am running out of ideas here.

Thanks for all the help, much appreciated.
Fair enough. I might have some gremlins after the first "raw snippet call occurrence in the front end". who knows?

@mplavala What you can try is to replace phpThumb call with the output and see whether the snippet converts that. If no, then there is some problem with the snippet accessing the resized images. If yes, then there is some problem with calling phpThumb inside webpBackground. In that case, maybe sit tight and I will try to implement srcset support soon. Let me know how it goes.

Confirming my latest srcset tests fyi in the DocLister row template...

1 phpthumb works as expected, but no webp conversion:
  Doclister &tpl
    [[phpthumb? &input=`[+image+]` &options=`w=1800,q=90`]] 1800w,
  source
    assets/cache/images/temp/photo-1200-2-1800x-594.jpg 1800w,

2 hardcoded phpthumb cache image = no webp conversion, exact same output in source:
  Doclister &tpl
    assets/cache/images/temp/photo-1200-2-1800x-594.jpg 1700w,
  source
    assets/cache/images/temp/photo-1200-2-1800x-594.jpg 1700w,

3 hardcoded original image = no webp conversion, exact same output in source:
  Doclister &tpl
    assets/images/temp/photo-1200-2.jpg 1600w,
  source
    assets/images/temp/photo-1200-2.jpg 1600w,

4 webpBackground std call = no webp conversion, original image listed in source:
  Doclister &tpl
    [!webpBackground? &src='[+image+]'!] 900w,
  source
    assets/images/temp/photo-1200-2.jpg 900w,

5 webpBackground call with hardcoded original image = no webp conversion, original image listed in source:
  Doclister &tpl
    [!webpBackground? &src='assets/images/temp/photo-1200-2.jpg'!] 700w
  source
    assets/images/temp/photo-1200-2.jpg 700w

6 webpBackground / phpthumb combo call = no webp conversion, phpthumb cached image listed in source:
  Doclister &tpl
    [!webpBackground? &src='[[phpthumb? &input='[+image+]' &options='w=650,q=90']]' !] 650w
  source
    assets/cache/images/temp/photo-1200-2-650x-cb2.jpg 650w

Confirming also that removing all srcset calls from the Doclister &tpl and simplifying to the std img call like below, also does not result in a webp conversion in the source - the original image is listed in the source code...

  Doclister &tpl
    <img src="[+image+]" />
  source
    <img src="assets/images/temp/photo-1200-2.jpg"

We've certainly done a lot of testing. Thanks again for all your help.

I understand that in my Evo 1.4.14 site, webpconverter may not work for me when used in snippet row templates for whatever mysterious reason,

@mplavala In that case, maybe sit tight and I will try to implement srcset support soon.

Very interested in this edit at your convenience regardless.

mplavala

nick0 Confirming also that removing all srcset calls from the Doclister &tpl and simplifying to the std img call like below, also does not result in a webp conversion in the source - the original image is listed in the source code...

This means that the problem is not with phpThumb being inside webpBackground, but the problem is that for some reason the image is not converted to WebP (maybe because the PHP can't save it?), or the converted image is not accessible, or it is broken (having size 0kB). Can you check whether there is image at assets/cache/webp/images/temp/photo-1200-2.jpg.webp and whether it is a valid image?
No more thing came to my mind: is the image displayed correctly during testing? Bare in mind that if the image does not exists, then the plugin will always output the original path, because it does not know what else to do.

FYI: I will add some debugging events, in the sense that if it happens that image conversion fails, or if some other check fails, then the code will let you know via Evo event log. I think this can help a lot, because it would eliminate a lot of the guesswork.

nick0

mplavala This means that the problem is not with phpThumb being inside webpBackground, but the problem is that for some reason the image is not converted to WebP (maybe because the PHP can't save it?), or the converted image is not accessible, or it is broken (having size 0kB).

Thanks so much for your further input @mplavala, much appreciated. Ok, understood. You prompted me to look at the webp cache images files on the server. The images exists and have file sizes. Will show you some screen caps down a little further in this message that show the images exist, their file sizes, comparisons etc.

mplavala Can you check whether there is image at assets/cache/webp/images/temp/photo-1200-2.jpg.webp and whether it is a valid image?

Sure thing. Confirming...
This is the original image - it has a file size of 156kb
/assets/images/temp/photo-1200-2.jpg
This is the webp converted image stored on the server - it has a file size of 271kb (woops)
/assets/cache/webp/images/temp/photo-1200-2.jpg.webp

The following screencaps show some comparisons between the original files. LHS = local files, RHS = webp cache server files.

This screencap shows the banners and photos in the temp folder. The webp images on the RHS are exact copies of my assets/images/temp folder. Many are smaller but some webp converted images are significantly larger**...

This screencap shows social icons. All webp converted images are larger than the originals**...

This screencap shows the original banners and photos on the LHS and the webp phpthumb conversions on the RHS. Most of these webp conversions are smaller but some webp images are also significantly larger**..

This screencap shows a copy of the phpthumb banners and photos on the LHS and the webp phpthumb conversions on the RHS. Most of these webp conversions are smaller but a few webp images are also significantly larger**..

** The larger .webp images highlights the need for the ability to manually exclude an image from webp conversion so we can always server the images with the smallest file sizes.

Looking at the above screencaps, does anything stand out?

I note that the webconverter direct conversion of images from the assets/images folder in their various subfolders (eg NON phpthumb converted images) look to have a folder path of:
/assets/cache/webp/images/temp (temp is my folder name in assets/images)
The phpthumb converted images look to have a folder path of:
/assets/cache/webp/cache/images/temp (temp is my folder name in assets/images)
Does that sounds right?

Could deleting the .webp image cache folder and/or phpthumb image cache folder fix things in DocLister row templates?

Any other ideas?

mplavala No more thing came to my mind: is the image displayed correctly during testing? Bare in mind that if the image does not exists, then the plugin will always output the original path, because it does not know what else to do.

Yes. The std images and the phpthumb images always display as expected on the various screen sizes.

mplavala FYI: I will add some debugging events, in the sense that if it happens that image conversion fails, or if some other check fails, then the code will let you know via Evo event log. I think this can help a lot, because it would eliminate a lot of the guesswork.

Fantastic, sounds great. Agreed, that could be very handy in this situation.

Thanks again for your help and have a fantastic day 🙂

mplavala

nick0 ** The larger .webp images highlights the need for the ability to manually exclude an image from webp conversion so we can always server the images with the smallest file sizes.

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. Also, we can automate this by displaying smaller of the two images without manual intervention. Adding a ticket. But some mechanism for manually excluding images will also be implemented.

nick0 Looking at the above screencaps, does anything stand out?

No, everything looks just about right.

nick0 Could deleting the .webp image cache folder and/or phpthumb image cache folder fix things in DocLister row templates?

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.

It seems that the plugin creates the WebP versions of the images, but then decides to not display them. This is possible, as before outputting the WebP image path, there are second checks whether the file exists and has non-zero size (this is checked in case some step in image conversion has failed). And this is what should be failing here for some reason, given that after deleting the folder cache/webp the plugin recreates everything.

nick0

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.
Strange.

		srcset="
			[!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=webp1800?

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?

phpThumbCacheIMcommandlineBase.txt
```
convert
```

phpThumbCacheIMversion.txt

6.9.10-68 Q16
Version: ImageMagick 6.9.10-68 Q16 x86_64 2021-01-06 https://imagemagick.org
Copyright: © 1999-2019 ImageMagick Studio LLC
License: https://imagemagick.org/script/license.php
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

phpThumbCacheIMwhichConvert.txt
```
/bin/convert
```
Thanks again for great help and suggestions. Have a super day 🙂

mplavala

Hi all and especially @nick0
So it took longer than expected, but there is a new version of the plugin/snippet. The changes:

There is now a debugging option for the plugin and snippet (they are independent of each other), debugging messages are logged in the System Events. The messages tell you why an image was not replaced by the WebP version. Also, if some basic checks fail (they look for the PHP functions mime_content_type and imagewebp) then an error is always logged.
You can now exclude images by using data-webpconverter-exclude="on" so that you can have some additional control over what the plugin does.
The code now checks whether the WebP image is smaller than the original. If not, the original image is displayed.

fourroses666

I love that plugin. Thanks allot!

nick0

Hi @mplavala, amazing news and work, thank you so much.

The image size checking works a treat in my tests. Likewise excluding images. Nice one and thank you 😀 .

Just tested the debugging feature and I can see this message for all social icons on the site...

Image does not exist. Image assets/images/social/icons-fb.png either does not exist, or is not accessible, or MIME type was not correctly detected.

This Facebook icon definitely exists at that path assets/images/social/icons-fb.png and can be seen on page and accessed directly in the browser. Any ideas on how I rectify this? (eg how do I check if it is not accessible to webp or if the MIME type is wrong and fix those?)

Also do you think there is any chance that an update will occur for the webp converter plugin to handle Srcset images (detailed earlier in this thread)? Or is that still considered too challenging for the plugin?

Many thanks again @mplavala .

mplavala

Hi @nick0,
That error basically means that the plugin tried to determine the MIME type of the image and the PHP function returned empty string. This can happen for images embedded from other pages, e.g.,

<img src="https://www.komplet.sk/assets/images/slider/image/n%C3%A1radie.png">

but I guess this is not the case. Other reason can be that the PHP cannot access the image - this should not happen on shared hosting, but can if your webadmin takes proactive approach to security.
But most importantly, this can happen if the PHP function mime_content_type does not recognize the image. This can be the case if the image is overly optimized. This can be the case for social media images.

I will split this debug message into two in order to make it clear whether PHP cannot find/access the image, or whether MIME type detection fails. I'll let you know when this is done. Other thing you can try is to download the image, open it in GIMP, Photoshop, or some other image processing software and export it to a new file. This could rebuild the missing info (if it is missing) and help PHP determine the MIME type.

For scrset, try to use the webpBackground snippet around your phpThumb call. I know this didn't work last time, but now maybe the debug helps. I will try to look into this as well.

nick0

Hi @mplavala,
Thanks for the help and further tweak.

Thanks for the info re MIME types. You're right, most images are heavily optimised. It's on shared hosting.
I commented out hot linking in the htaccess file in case that was affecting things - no change.

Splitting the error message is helping narrow the problem. No MIME type errors, only "WebP Converter - image does not exist" errors now. See 2 example warnings below

This system event warning is presumably from my page with the alias "demos"...
WebP Converter - image does not exist - System Events
Warning!
Event Id: 	1
Source: 	WebP Converter - image does not exist
Date: 	30-09-2021 15:54:26
User: 	
Image assets/images/social/icons-yt.png does not exist. Either there is no file at /home/mydemosite/public_html/demos/assets/images/social/icons-yt.png, or the path is not accessible. 

This system even warning is presumably from my page with the alias "page-1"...
WebP Converter - image does not exist - System Events
Warning!
Event Id: 	1 
Source: 	WebP Converter - image does not exist
Date: 	30-09-2021 15:54:42 	User: 	
Image assets/images/social/icons-fb.png does not exist. Either there is no file at /home/mydemosite/public_html/page-1/assets/images/social/icons-fb.png, or the path is not accessible.

In the above social icon examples:

there is an image at: domain.com/assets/images/social/icons-fb.png
there is NO image at: domain.com/page-1/assets/images/social/icons-fb.png

Is WebP Converter adding the page alias into the image paths? If so, how do I exclude the page alias out of the image path to correct the error?

mplavala For scrset, try to use the webpBackground snippet around your phpThumb call. I know this didn't work last time, but now maybe the debug helps. I will try to look into this as well.

You beauty. This now appears to be working quite well with the following type of usage. I don't think it works in all of my usages, but perhaps more than I think because the webp images may be bigger than the originals in some of those instances.
Excellent work and thank you kindly

<img src="[+image+]"
	srcset="
		[!webpBackground? &src=`[+image+]`!] 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,	
		[!webpBackground? &src=`[[phpthumb? &input=`[+image+]` &options=`w=1000,q=90`]]`!] 1000w,	
		[!webpBackground? &src=`[[phpthumb? &input=`[+image+]` &options=`w=800,q=90`]]`!] 800w,	
		[!webpBackground? &src=`[[phpthumb? &input=`[+image+]` &options=`w=650,q=90`]]`!] 650w,	
		[!webpBackground? &src=`[[phpthumb? &input=`[+image+]` &options=`w=480,q=90`]]`!] 480w,	
		[!webpBackground? &src=`[[phpthumb? &input=`[+image+]` &options=`w=300,q=90`]]`!] 300w" 
	sizes="100vw"
	[+pagetitle:isnot=``:then=` title="[+pagetitle+]"`+] alt="[+pagetitle+] image" />

Thanks @mplavala

mplavala

@nick0 so the debug message is split, change is uploaded to the github repo. If the plugin cannot find the original image file, it tells you explicitly and it also mentions where it looked for (so you can check via FTP). If the MIME type evaluates to empty string, this gives a different debug message that MIME type cannot be correctly detected. If you ever get that debug message, please link/send me the image, so I can use it for testing (I have no such image currently).

mplavala

nick0 Is WebP Converter adding the page alias into the image paths? If so, how do I exclude the page alias out of the image path to correct the error?

Yes! This is documented on the github page as well, but the story goes like this: if you use friendly URLs and go to a page with URL https://www.example.com/parent/child.html or https://www.example.com/parent/child or https://www.example.com/parent/ and there is an image given as <img src="folder/image.jpg"> then the browser by default thinks that the image is located at https://www.example.com/parent/folder/image.jpg. For this reason also the plugin adds the web path to the image path when looking for it.

I know that there are ways to change this behavior by using the <base> tag (let me know if you use something else). Currently the plugin does not support <base> tags and it is borderline impossible for the snippet to support it. For this reason I would rather not add them, because I would prefer to keep the behavior of the plugin and snippet consistent.

Luckily, there is an easy solution: use absolute paths, i.e., use paths starting with /, for example: <img src="/folder/image.jpg"> This will (irrespective of the base tag) always point to https://www.example.com/folder/image.jpg. Also, this will then point the plugin to the correct image file.

nick0

mplavala Yes! This is documented on the github page as well, but the story goes like this: if you use friendly URLs and go to a page with URL https://www.example.com/parent/child.html or https://www.example.com/parent/child or https://www.example.com/parent/ and there is an image given as <img src="folder/image.jpg"> then the browser by default thinks that the image is located at https://www.example.com/parent/folder/image.jpg. For this reason also the plugin adds the web path to the image path when looking for it.

Ahhhhhhhhh thank you so much for taking the time to explain this so clearly. This has provided a solution for the srcset not working. See below for details.

mplavala I know that there are ways to change this behavior by using the <base> tag (let me know if you use something else). Currently the plugin does not support <base> tags and it is borderline impossible for the snippet to support it. For this reason I would rather not add them, because I would prefer to keep the behavior of the plugin and snippet consistent.

Agreed, good call and thank you for the info.
FYI I use '<base href="[(site_url)]">' in the head chunk which works well for everything else.

mplavala Luckily, there is an easy solution: use absolute paths, i.e., use paths starting with /, for example: <img src="/folder/image.jpg"> This will (irrespective of the base tag) always point to https://www.example.com/folder/image.jpg. Also, this will then point the plugin to the correct image file.

Wowwwwww! That is fantastic! Thank you so so much for your help with this.
Adding a forward slash at the front of all straight image paths, webpBackground image paths and webpBackground-phpthumb combo paths to all chunks, row templates etc fixed all error warnings pertaining to ""WebP Converter - image does not exist" errors... I no longer receive any of these errors - amazing!

Example usage of each fyi is below...

straight image paths
   <img src="/[*banner*]" />

webpBackground image paths
   [!webpBackground? &src=`/[*banner*]`!]

webpBackground-phpthumb combo paths 
   [!webpBackground? &src=`/[[phpthumb? &input=`[*banner*]` &options=`w=1600,q=90`]]`!] 1600w

NB. Note that for webpBackground and phpthumb to work together, the forward slash must be BEFORE the phpthumb call like so:

[!webpBackground? &src=`/[[phpthumb?...`

If the forward slash is put instead in the phpthumb input like this, webp doesn't seem to work.

[!webpBackground? &src=`[[phpthumb? &input=`/[*banner*]`... `

Full working WebP Converter / webpBackground / phpthumb srcset example shown below in case anyone is interested...

<div>
	<img src="/[*banner*]" 
		srcset="
			[!webpBackground? &src=`/[*banner*]`!] 1800w, 
			[!webpBackground? &src=`/[[phpthumb? &input=`[*banner*]` &options=`w=1600,q=90`]]`!] 1600w, 
			[!webpBackground? &src=`/[[phpthumb? &input=`[*banner*]` &options=`w=1400,q=90`]]`!] 1400w,
			[!webpBackground? &src=`/[[phpthumb? &input=`[*banner*]` &options=`w=1200,q=90`]]`!] 1200w,	
			[!webpBackground? &src=`/[[phpthumb? &input=`[*banner*]` &options=`w=1000,q=90`]]`!] 1000w,	
			[!webpBackground? &src=`/[[phpthumb? &input=`[*banner*]` &options=`w=800,q=90`]]`!] 800w,	
			[!webpBackground? &src=`/[[phpthumb? &input=`[*banner*]` &options=`w=650,q=90`]]`!] 650w,	
			[!webpBackground? &src=`/[[phpthumb? &input=`[*banner*]` &options=`w=480,q=90`]]`!] 480w,	
			[!webpBackground? &src=`/[[phpthumb? &input=`[*banner*]` &options=`w=300,q=90`]]`!] 300w"
		sizes="100vw"
		title="[*pagetitle*]" alt="[*pagetitle*] image" />
</div>

Thank you @mplavala - you are a legend and I absolutely love your work 🙂

mplavala

nick0 Glad that it works. But this makes me feel a bit bad, because including the / everywhere makes the code inside Evolution CMS quite messy and prone to error, because it basically violates the DRY (don't repeat yourself) principle. But the obvious upside is a way cleaner HTML output.

I will take a look whether <base> tag can be reasonably implemented, then you could simply use <base href="/"> to do essentially the same thing. This will likely take some time.

Also, if you agree, I will use some of your working examples in the plugin/snippet documentation.

nick0

mplavala nick0 Glad that it works. But this makes me feel a bit bad, because including the / everywhere makes the code inside Evolution CMS quite messy and prone to error, because it basically violates the DRY (don't repeat yourself) principle. But the obvious upside is a way cleaner HTML output.
I will take a look whether <base> tag can be reasonably implemented, then you could simply use <base href="/"> to do essentially the same thing. This will likely take some time.

Thanks mplavala... don';'t feel bad, it's working 😀.
I agree that the current forward slash addition provides cleaner and easier to edit HTML output than using "base href". Unless there is some other better way for webpBackground and phpthumb to work better together to handle srcset images, the forward slash is a pretty simple and neat solution. It would feel like doubling up when the "base href" is already in the document head - perhaps webpBackground could take the cue from that first somehow??
Happy to be the guinea pig for testing any tweaks when ready, just sing out.

mplavala Also, if you agree, I will use some of your working examples in the plugin/snippet documentation.

Sure thing, please do. Great idea to help other Evo users with working examples in the documentation 😃 . Nice one.

Neoziox

Hi everybody!

I use this:

<source media="(min-width: 1215px)"
      srcset="[!webpBackground? &src=`/[[phpthumb? &input=`[+image+]` &options=`w=700,h=450,zc=1`]]`!], [!webpBackground? &src=`/[[phpthumb? &input=`[+image+]` &options=`w=1050,h=675,zc=1`]]`!] 1.5x">

But I have this result:

<source media="(min-width: 1215px)"
      srcset="/assets/cache/images/pourquoi-evo/jordan-opel-ybltrkjhpre-unsplash-700x450-6a5.jpg, /assets/cache/images/pourquoi-evo/jordan-opel-ybltrkjhpre-unsplash-1050x675-770.jpg 1.5x">

I read above that doesn't works with multiTV or DocLister. Is this still the same issue? How can I fix it? I failed to figure out if there is a solution to this issue.

Can you help me please?

mplavala

Neoziox Hi. It seems that the snippet is returning the original path instead of the webp path. In the snippet configuration tab you can turn on logging of debugging messages, then refresh the page and the snippet will log System Events explaining why it did what it did. Let me know if this helps. If not, please post the message and I will try to explain what happens. Note that in some cases (e.g. when the webp image is smaller than the original) the plugin/snippet returns the original path. But if this is the case, then it will be logged.

Also the slash before the phpThumb call should not be necessary, I would try to remove it.

And the plugin/snippet should work just fine with multiTV and DocLister, in fact I use them together in few pages. But if you find any bug let me know and I will do my best to fix it.

Neoziox

mplavala I don't understand because I put Log debugging messages on Yes and I have no messages in the System Events. I clear the cache in Evo and in the browser. Still no messages.

-- EDIT --
I tried on iPad yesterday. On my computer, I have this error:
Image /assets/cache/images/pourquoi-evo/jordan-opel-ybltrkjhpre-unsplash-750x850-ce9.jpg was supposed to be replaced by /home/www/folder-1/mywebsite/assets/cache/webp/cache/images/pourquoi-evo/jordan-opel-ybltrkjhpre-unsplash-750x850-ce9.jpg.webp, but the WebP version does not exist, or is corrupted.

Neoziox

mplavala I checked the files and they all exist. I tried downloading and opening them, I tried opening the files directly in my browser and in all my tests I was able to open, they are not corrupted.
Why the snippet webpBackground use the path /home/www/folder-1/mywebsite/assets/cache/webp/cache/images/ instead of /assets/cache/images/? Is this normal behavior? With my knowledge, I guess that is what is causing the problem. Maybe I'm wrong. But in all cases, I don't know how can I solve the issue.

mplavala

Neoziox I don't understand because I put Log debugging messages on Yes and I have no messages in the System Events. I clear the cache in Evo and in the browser. Still no messages.

Please note that plugin and snippet have independent options to turn on the debugging messages. This is due to the design of Evo. Also you need to visit the page where the problem is as user, since only then the plugin/snippet is executed and only then messages are logged. But it seems you figured this out in the meantime.