issacchua

Hi Marko,

Would you be specific about what might cause the error? I have tried unset all the security headers but it is still not doing any good after disabling and renabling (I am adding them back now so).

Hello Marko,

I manually click on the convert button. It has been 8 hours now and I check the status is still showing Processing.

The responses are POST 200 and it kept requesting for every 1-2 seconds (for each image that is in Processing).

The website link url is: https://www.test-playground-2.menusifudemos.com/

Thank you for your time to look into this matter, thanks!

Thanks Marko,

I will check that later, thanks!!

Marking it as resolved.

Mark as resolved.

Ok, thanks for your response!

Thanks Marco, awaiting for your response on item 3. ??

Hi Marko,

1. Thanks for clarifying!

2. Thanks for clarifying! Is it documented somewhere on the website? I only saw this limitation from a comment post, wondering if there’s a document that I can refer to.

3. Thanks! Hopefully there is a programmatical way (API call or php function for example) to perform such task.

4. I will check and install Imagic to support webp extension. I don’t have Nginx over Apache so that should be fine.

Thanks again!

Hi Marko,

To clarify, when I convert the image on my server, it will automatically upload (and replace) the image on origin (in my case, S3 from AWS).

If we don’t send the invalidate request to CDN (in my case, Cloudfront from AWS), then the Cloudfront will continue to serve the image from its cache version (the original image that is cached in Cloudfront) until the cache version is expired.

Is my understanding correct? Thanks!

Hi Marko,

Thanks for your reply. I am looking to decrease the image size is what I meant by compression. If converting to webp works, I won’t mind getting that.

No plugin can optimize or compress the images that are already on the CDN. This being said, once compressed or optimized, you will need to purge the CDN cache in order for the new optimized images to be uploaded and served from the CDN.

I am currently using W3 Total Cache CDN option so that images are offloaded to CDN. If using Image Service Extension, does the webp file will store on the S3 as well (same path as the regular image that is uploaded to S3), and that the WordPress will simply load the webp resource rather than the image resource from CDN?

Hi Marko,

It actually can be as simple as:

/

I am using this works as well:

^(.*\/)([^\/]*)$

Yes, that works! Thanks Marco!

I need to figure out the regex to exclude everything in the upload directory with different subdirectories now.

Hi Marko,

Thanks for your reply. I actually wanted the images to upload to CDN, however, on the website, we still display the file served from local. (I know I know, it is a weird request to ask…)

So to give an example, when I upload a file in media library, I would like the file to be uploaded to CDN as well. However, on my web page that displays the image, I want that image to load from local host instead of CDN. Hopefully, there is an option that allowed me to do such switch.

Hello Marko,

I decided to use the gzip from Nginx for the compression instead of the one from W3 Cache. So I will mark it as resolved. Thank you for your time.

I did some research:

So basically if I don’t enable the Gzip from Browser Cache section (provided by W3 cache), I get the page size about 9.7kb over 34kb.

If I enable it (and allow manually reload the page), I get the page size 8.5kb over 34kb.

I guess that might be one of the advantages to use the compression provided by W3 Cache?

But still, hopefully this issue can still be identified though. Otherwise I am just pulling off my hairs figuring why…??

Yes, I know that is super weird.

I have replicated the same site on another domain:

https://www.test-2.menusifudemos.com/

Both are hosted on the same server with the same configuration, except that on the second one, I update master.php so that on the line 591, I change the value to false:

“browsercache.html.compression”: false,

The test-2.menusifudemos.com does not have the same issue as test.menusifudemos.com.

Since the nginx’s configuration file is not modified, so the spec is still the same as before.

I use dev tools to inspect the HTTP requests, its header contains content-encoding: gzip , and the size is indeed being compressed as well (6.3kb/17.8kb).

• This reply was modified 3 years, 9 months ago by issacchua.