WordPress Images Not Conforming to Manual Width

Hi Reed,

Thank you for contacting us.

I have already replied to your message through our support system as well however I am sharing my reply here too.

This kind of issue should be related to the WebP display option when using picture tags as sometimes it can be risky. If you deactivate the display WebP option(Settings > Imagify) and clear your caches is the issue fixed? Can you please check that? If so, the solution, in this case, would be to choose the rewrite rules way to display your WebP images(Settings > Imagify) unless you are using a Cloudflare/ CDN.

If the issue is happening because of WebP display option it means that your theme does not handle <picture> tags as same as <img> tags. When using WebP display option (using <picture> tags), the HTML output is changed by wrapping up <picture> tag on top of <img> tag. The CSS code that handles <img> tag is not applied properly in that case. It would be ideal to contact your theme provider and ask them to check this in more detail, as it would be great improvement for their theme to make full compatibility for using picture tags.

Or you can check one of the two following options(if you are not able to use rewrite rules).
– You can try to use the following HTML class that can be added to the specific images, that are not displaying correctly, to prevent WebP display via <picture> tag replacement (the optimized JPG/PNG versions will be displayed instead). If you can add this HTML class to all of the specific images you don’t want to display in WebP, then the rest of the images can still be displayed in WebP format.

imagify-no-webp

– You could try to delete the WebP version of those images through FTP. WebP images will be located in the same folder in which the original format version of the images is located. So if the original format image is located at wp-content/uploads/2020/02/image.jpg, then its WebP version will be at wp-content/uploads/2020/02/image.jpg.webp You can delete WebP versions of images by connecting directly to the files on your website’s server using an FTP program. Using an FTP program, you will be able to delete your WebP files individually or in larger groups at the same time.
Depending on which FTP program you are using, you can search for .webp or *.webp, which will return all WebP images and you can then quickly select them all and delete. But be careful, as this would also return images or files that just have .webp somewhere in their name or URL.
You can find further details on the following link https://imagify.io/documentation/delete-webp-images-website/

Let me know if you need any further assistance. I’ll be happy to help.

Best Regards,

Ioanna

FYI – this is the reply I received from my theme support and it resolved the issue:

for the solution, try adding this CSS: picture { display: block; }

For the problem.

When you set the size of a core Image Block, it adds CSS Class and Styles Attributes to the <img> HTML.

https://app.screencast.com/JLa14iFev9Wlc

And WP adds CSS specifically for an img eg. .wp-block-image img { box-sizing: border-box; height: auto; max-width: 100%; vertical-align: bottom; }

The Theme itself does not control the inline style or that CSS.

When that plugin converts the image, it wraps the img inside a <picture> tag and it MOVES the CSS Class and Style Attributes from the img tag to the <picture> tag. See here:

https://app.screencast.com/tKNZGDHJwDFOA

And that is where the problem lies.

A <picture> elements main purpose is a wrapper to provide source information, it itself is an inline element that does not have any width and height attributes and therefore it does not occupy any real space on the page.

And therefore that inline style which sets the width will not work there.

The CSS i provided up top changes the picture display property to a block so it can accept the width style.

The ideal solution would be that the Plugin does NOT move the inline style from the img tag and that way the core Image Block would work as expected.

It does seem that adding that CSS property to the picture element fixes it for me too, but it seems Imagify is actually doing something wrong here according to their reply?