This support ticket is created 4 years, 5 months ago. There's a good chance that you are reading advice that it now obsolete.
This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.
Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.
No supporters are available to work today on Toolset forum. Feel free to create tickets and we will handle it as soon as we are online. Thank you for your understanding.
Hi, I need to replace images format in my website from jpeg/png to webp.
To do it I choose Imagify plugin it has function "Create webp versions of images" - hidden link
So, I have optimized images on my site with Imagify plugin and I expected that all images on the all pages would be in webp format.
But for some reason this did not happen. Images which used in views still display in jpeg/png format, other images was converted good.
---- Example ----
Page - hidden link
Image - Genesis casino logo - hidden link
Result of convertation - hidden link (all is okey, insted jpg/png I see webp image)
If watch at this image (more precisely, its thumbnail, which has also been optimized - hidden link ) inside view loop on the main page we will see that image doesn't display in webp format - hidden link
There is a pattern, if the images are inside the loop they are not converted to webp.
Please help me figure out what is the reason and how to fix it.
I tried to replicate this issue on my end but all my images in my view loop gets rendered with the correct information. See Screenshot
I've also tested multiple instances where I tested the following:
1. Classic view after optimizing the images.
2. A block view created directly on the page.
3. Display the image field directly through the post template.
In each case above the image field renders in the correct tag with reference to the .webp format.
Can you try re-optimizing your images once more as well as recreating the view to see if the issue still remains.
If I use size='thumbnail' all works good because it is one of default wordpress image sizes. But I need to use my own sizes (like size='custom' width='124' height='70') and here the problems begin ...
Please try using in your shortcode size='custom', and not size='thumbnail' and tell me, is it possible to reproduce the problem?
Ok so I can understand why this is the issue now. Unfortunately there wont be much that we can do here because the images are being regenerated and cropped to their new sizes.
I would recommend that you get in touch with the imagify team to see if they have a solution for when an image is dynamically generated with a new size.
What i'm trying to explain is if the Plugins don't support the use of Custom Image sizes then they won't benefit from the optimization.
If you take a look when our plugin is rendering the image it adds the "wpcf_160x150.jpg" at the end which essentially means the image is pointing to a location that technically doesn't exist.
Hence why I say that the thumbnails for toolset are being generated dynamically.
There isn't much that we can do about this given the issue, however what I can do is to escalate this under a compatibility issue but I cannot guarantee that this issue will be fixed any time soon.
> If you take a look when our plugin is rendering the image it adds the "wpcf_160x150.jpg" at the end which essentially means the image is pointing to a location that technically doesn't exist.
I do not understand, I go to the server and see these images. They are static and are generated only once, why plugins do not see them? - hidden link
>There isn't much that we can do about this given the issue, however what I can do is to escalate this under a compatibility issue but I cannot guarantee that this issue will be fixed any time soon.
I would be grateful for that. Because this problem makes Toolset extremely unfriendly in terms of working with image optimization and site speed.
Thank you for the continued patience, I've seen where this issue has been fixed from our Blocks version 1.3
If you are still running any version below version 1.3 then I would advise that you perform an update and if you're still experiencing this issue then I recommend opening a new ticket.