adamewww

The Resize Image button will only show up if the image can be resized and is outside of the parameters you set in the settings.

Hi Lavinya,
So, not really something that our plugin is doing, but more an issue with how WordPress and your theme are handling your images.
That having been said, the image sizes that you are seeing, I don’t see that you excluded them in your function that you added. For example, you excluded 1536×1536 but the one showing up is 1536×864. Are there other add_image_size rules in your functions.php? Have you tried regenerating thumbnails? Is something in your theme adding other sizes?

If you have run the batch once, you shouldn’t need to do it again. If you leave imsanity active, it should resize as the images are loaded. Could you describe why you are running the process again?

Also, I erred, I was thinking of our EWWW product which keeps the table. Yes, it is going to scan the files again.

Hello,

The system keeps a record in a table in your database of what it has resized. Is your database removing it perhaps? Or is there a permission issue?

There shouldn’t be any issues with using it, no. If wanted to, if you come across anything in particular you could send it in to our contact form: https://ewww.io/contact-us/ That may help us with compatibility testing.

Hey Jonathan,

Thanks for sending this over! We don’t currently support PHP8.1 yet but it’s in the works.
https://docs.ewww.io/article/55-upgrading-php

I’m glad to hear it! For your WebP question, as a general rule, it’s not a good idea to have two things trying to do the same thing as you can get conflicts. So, if you can get rid of one of them, it probably wouldn’t be a bad idea.

I believe you sent in a support email as well, however, if it was someone else, I apologize. To answer your question, this is often a lazy load conflict. The “base64” is a lazy load placeholder. I would recommend trying to disable lazy load in the plugin settings and seeing if that fixes it. If it does, you may want to check if you have anything else doing lazy load and then choose which you want to use. Having more than one thing doing the same thing can cause conflicts like this.

If you want to use the Easy IO CDN, then no, each subdomain is most likely it’s own site and you would therefore need one of the multi-site plans. If you want to use the API Key for local compression, that is site agnostic so you can use that on as many sites as you like.

I think at this point we may need to look more in depth into it. Can you contact us at https://ewww.io/contact-us/ and send over the system info from the support tab of the plugin?

Hey Benjamin,

I could be way off but it looks like the conflict is specifically with Lazy load, as it looks like the comparison is trying to load the placeholder as opposed to the file from Photon’s CDN. Are you using our lazy loader? If so, try disabling that (having more than one lazy load running can cause other conflicts anyway).

This is odd. It seems like perhaps the theme is doing something to maybe prevent lazy load, also I don’t see that our lazy load is running, but it is adding a lazyload class in there, which may be why our code is being bypassed. Additionally, that initial image doesn’t have any webp in the srcset like the rest of the images do, nor does it have a data-srcset-webp. In short, it’s seeming like JS WebP isn’t compatible with how your theme/builder is handling those first images specifically because of how they are trying to say trick lazy loading.
So, I would suggest going through your theme’s settings and turning off anything related to lazy load. Then, I would also try turning off WP Rocket’s lazy load and turning ours on and seeing if it can then grab those images.

The resizing is permanent, so again, no.

If you already have something (your CDN provider) giving you image optimization, then no, you don’t need to also use this. In fact, it’s generally a good idea to not have more than one thing trying to do the same thing. The “Remove Originals” option gets rid of the original image after WordPress has created a “scaled” version of an overly large image.

Hi BR,

That pastebin link is private so I can’t view it. Are you using .htaccess rules or JS WebP to serve your WebP images? Does it not show as WebP in the network tab of the dev console?
Since you mention that you have WebP versions of the images, it must be the delivery that is suspect. This document goes through the different options there: WebP Delivery