jpeg.webp, jpg.webp, png.webp generated and not served

It’s definitely possible you need that option in Cache Enabler, but I’d use whatever method you used on the staging site:
1. “additional cached version…” in Cache Enabler
2. The .htaccess rules from EWWW IO
3. JS WebP Rewriting
4. Or <picture> WebP Rewriting

Creating the .webp images is only half the equation, you need one of those four methods to rewrite the URLs and deliver the actual WebP images.

Mhhh, i use JS WebP Rewriting on the live site and the following (that i have forgotten) on the staging site:

#EWWW Image Optimizier WebP-Auslieferung
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_ACCEPT} image/webp
RewriteCond %{REQUEST_FILENAME} (.*)\.(jpe?g|png)$
RewriteCond %{REQUEST_FILENAME}\.webp -f
RewriteCond %{QUERY_STRING} !type=original
RewriteRule (.+)\.(jpe?g|png)$ %{REQUEST_FILENAME}.webp [T=image/webp,E=accept:1,L]
</IfModule>
<IfModule mod_headers.c>
Header append Vary Accept env=REDIRECT_accept
</IfModule>
AddType image/webp .webp
#Ende EWWW Image Optimizier

For testing i copied these rules in the .htaccess of my live site. That changed the configuration options displayed in the EWWW Image Optimizer WordPress-Backend, so i had only two options:

JPG/PNG to WebP (activated)
Force WebP

But the live site still serves no webp-pictures. ;(

Ah, if you had JS WebP, I just realized you’re probably being hit by a bug which prevents it from working properly.
Go ahead and remove the .htaccess rules on the live site, and update from the latest code on GitHub (or wait for the release early next week): https://docs.ewww.io/article/73-update-from-github

update: and then, of course, re-enable JS WebP

• This reply was modified 4 years, 6 months ago by nosilver4u.

Ok, i’ve downloaded the version provided by you through the link and installed it, but it has the same version number: 5.3

And … i’ve deleted the rules in my .htaccess but i still see the same configuration page in the EWWW IO Plugin. WTF? So i can’t re-enable JS WebP.

Have i overlooked something?

If you don’t see JS WebP, that usually means Cache Enabler’s webp option is enabled.
But yes, it will still say 5.3, as I don’t bump the version numbers on GitHub between official releases.

Ahh! That was the trick. ??
I’ve disabled the Cache Enabler’s webp option and … bing! … the new options including the JS WebP Rewrting appear in EWWW IO again. Thx for the important hint. ??

But, as soon i’ve re-anable the webp option in Cache Enabler, the new options including the JS WebP Rewrting disappear in EWWW IO again? Does it make sense?

And … my browsers still don’t serve webp-pictures. ;(

• This reply was modified 4 years, 6 months ago by The-Dude.
• This reply was modified 4 years, 6 months ago by The-Dude.

cleared all caches? What’s your URL?

https://www.smarthomearea.de/
Cleared all caches

Disable the Cache Enabler option, JS WebP cannot be enabled at the same time, so JS WebP will disable itself.
Once the Cache Enabler WebP option is off, turn on JS WebP, and then clear all caches. Otherwise, if you want to use the Cache Enabler WebP option, you’ll have to ask the Cache Enabler folks why their plugin doesn’t work.

Oh, i thought both plugins work together or at least support each other.
Good to know! ??

I’ve disabled the webp option in Cache Enabler and use now the JS WebP Rewrite by EWWW IO.
And surprise … WordPress serves webp-images … somehow.

But the problem is not finally solved.

In Google Chrom 81.0.4044.129 my live site serves still images with the double extension jpg.webp, but the developer tools identifies them as type JPEG.

In Opera 68.0.3618.63 my live site serves images with the double extension jpg.webp / jpeg.webp and the developer tools identifies them as type WEBP. But some images with the single extension .jpg where identified as type WEBP too.

In Firefox 75 my live site serves images with the double extension jpg.webp / jpeg.webp and the developer tools identifies them as type JPEG, not WEBP.

This is really, really confusing me ??. What information should i trust?

Look at the response headers for all 3, they should be identical, and it probably means your server doesn’t know about the image/webp file type and just sends them as image/jpeg.
Specifically, check the content-type header, that’s usually what Chrome displays, I’m guessing Opera is ignoring that header in the dev tools and doing actual mime/magic detection based on the file header.

All of the browsers do this sort of mime/magic detection anyway when they render an image, so I’m not sure why Chrome likes to display the server-based file type rather than what the rendering engine detected, but maybe they’ll change that some day.

You can also do one other thing to verify the file type. Download one of the .webp images, and open it in a hex-editor, and you should see the WebP file header right at the top.

First, thx 4 your fast answers. I don’t take that for granted. ??????

Ok, i’ll digg deeper now and give you feedback. ??

I fixed the wrong detection from webp images with this little line in my htaccess: ??

# Add Support for WebP
AddType image/webp webp

And only for caching reason these lines too:

setEnvIfNoCase REQUEST_URI \.(?:gif|jpg|jpeg|png|svg|webp)$ no-gzip dont-vary

<IfModule mod_headers.c>
<FilesMatch “\.(ico|pdf|flv|swf|gif|png|jpg|jpeg|webp)$”>
Header set Cache-Control “max-age=31536000, public”
</FilesMatch>
</IfModule>

<IfModule mod_expires.c>
ExpiresActive on
ExpiresByType image/webp “access plus 1 year”
</IfModule>

• This reply was modified 4 years, 6 months ago by The-Dude.
• This reply was modified 4 years, 6 months ago by The-Dude.