issacchua

Hi Marko,

Thanks for your reply. I will be waiting ??

Hello @vmarko ,

Thanks for your reply. Does it mean that the next version this issue will be fixed right?

Thanks ??

Hi Marko,

Thanks for your reply. Is it possible to do it in a simpler way, which we load the image of .webp extension directly?

For example, I have both .jpg and .webp same image file in the media library, if I choose to show .webp image, then we load the image with .webp extension as opposed to what the current state is (file extension shows .jpg but load content-type image/webp ).

Thanks again!

Thanks @vmarko , I will be waiting!

Thanks for you reply.

Is there anywhere else that I can look into on my own to further troubleshoot this issue?

To iterate the problem, this problem only happened when I choose to offload images from cloudfront (s3 origin) , if I disable Cloudfront, webp images are served locally without any problem. Webp images are uploaded to S3 as well.

I suspect it has something to do with redirection. When disabling CDN, the nginx is able to handle the redirection to webp images by using try_files method. However, with CDN enabled, the images are actually loaded from Cloudfront and hence no such try_files functionality applied.

Please let me know if you have anything that can help me with solving this issue, thanks!

Hello @vmarko ,

Any updates on this? A reply on the progress would mean a lot to me, thanks!

Hello @vmarko ,

Any updates on this? Thanks!

Hello @vmarko ,

I am following up this case, let me know if you have any updates ??

Awesome, thanks Marko!

Hi Marko,

Any updates on this?

Hi Marko,

Thanks for your reply. It is quite frustrating that the images failed to get a response from the server resulting in the server cannot handle the request at that time. In a even worse case, the new file is uploaded which is supposed to convert automatically, but because the server failed to respond, the image does not get to convert.

In order to make the process a little bit smoother, here is what I would suggest:
When the conversion is triggered, in spite of of waiting to get response back from the server, we can mark the status to be Processing right away. Since we are relying on the scheduled cron job to download the converted images from W3 server, we can apply the same idea here too. We use cron job to send requests to W3 server, even if the request is failing due to server overloading, the cron job will resend the request once again till the server is responding with something that the code is familiar with, to be it an error or success message.

This whole image-convert process can run in the background without too much user interference. Pro users have higer priorities where their images are converted instantly (or in the top of the queue), regular users can have their images converted when the server is not so busy and that’s fine, as long as the image gets converted eventually.

What do you think? ??

Mi Marko,

You can check my website: https://www.test-playground-2.menusifudemos.com/

One of the images link as below:
https://website-cdn.menusifu.com/wp-content/uploads/test-playground-2.menusifudemos.com/2022/05/8025f0ee5ebe7801c1d8c67c636eb30d-1400-scaled.jpg

You can find the webp version as well:
https://website-cdn.menusifu.com/wp-content/uploads/test-playground-2.menusifudemos.com/2022/05/8025f0ee5ebe7801c1d8c67c636eb30d-1400-scaled.webp

I believe I don’t have any header set up for Amazon S3 that it will respect the origin header.

Thanks Marko for your reply, I will find some other way round, thanks!

Hello, I found the issue of why it is not converting.

It is because the cron job is disabled in the wp-config.php. Hope this helps whoever is having same problem.

Have a good one!

I am not sure if it is because I don’t have Imagick installed?

I am referring to this documentation: https://www.boldgrid.com/support/w3-total-cache/image-service/

Seems like using GD is also possible as long as the GD also supports webp format right?