George Sexton

I kept investigating, and got this:

SVGs aren’t officially treated as images
By default WordPress only considers GIF, JPEG, PNG (and, in recent versions, WebP) as “images.” That check lives in wp_attachment_is_image() — SVGs aren’t on that list.
When you call wp_get_attachment_image(), under the hood it uses image_downsize() to fetch URL, width and height. If wp_attachment_is_image() is false and there’s no metadata for a “full” size, image_downsize() simply returns false, which then causes the <img> generator to skip outputting any width or height attributes. developer.ww.wp.xz.cn

This explains why when I add width and height attributes to my generated output, they’re getting removed. I guess that also means I can’t work around the issue by adding the attributes.

On my demo site that has my plugin, I installed smush. I went through and did the install. The only option I changed from the default was “Compress My Full Size Images” during the wizard setup.

After doing that, my icons are now:

<img decoding="async" id="imgNavLeftcdaily_monthview" data-year="2025" data-month="6" data-direction="-1" class=CDNavIcon data-src="https://wpdemo.mhsoftware.com/wp-content/plugins/connect-daily-web-calendar/images/left-arrow.svg" alt="Previous Month" title="Previous Month" src="data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==" class="lazyload">

If I turn off lazy loading for .svg then I get:

<img decoding="async" data-year="2025" data-month="6" data-direction="1" class=CDNavIcon src="https://wpdemo.mhsoftware.com/wp-content/plugins/connect-daily-web-calendar/images/right-arrow.svg" alt="Next Month" title="Next Month">

This appears to be the relevant code from your plugin:

// File: core/lazy-load/class-lazy-load-transform.php
// Lines ~117–123

private function update_element_attributes_for_lazy_load( Element $element, $replace_attributes ) {
    // Move each real attribute (e.g. 'src', 'srcset', 'sizes') into data-src* versions
    $this->replace_attributes_with_data_attributes( $element, $replace_attributes );

    // Insert a tiny, blank placeholder src (keep markup valid)
    $element->add_attribute(
        new Element_Attribute( 'src', self::TEMP_SRC )
    );

    // Add the CSS class that triggers the JS/CSS lazy-loader
    $this->add_lazy_load_class( $element );
}

So the code above sticks in the dummy image, and evidently the code that handles lazy loading replaces the src on-demand. But that’s failing for some reason. I ran the page with the debugger turned on and I’m not seeing anything. By any chance does lazy load try to retrieve images from a compressed image directory?

Kris,

Let me start over. I’m a plugin vendor also. When customers use my plugin with your plugin, there’s a problem.

Your plugin is attempting to in-line an SVG icon, and only generating a single pixel invisible GIF. Here’s an example of your output code:

<img decoding=”async” id=”imgNavLeftcdaily_monthview” data-year=”2025“
data-month=”6” data-direction=”-1” class=CDNavIcon
data-src=”https://www.mycustomer.net/wp-content/plugins/connect-daily-web-calendar/images/left-arrow.svg“
alt=”Previous Month” title=”Previous Month“
src=”data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==“
class=”lazyload“>

My customers then call me with complaints that my product isn’t working. This has happened at least 5 times. This isn’t a problem I can fix by changing a setting in your plugin. I need your help.

You stated in your last post the Smush doesn’t have the ability to compress SVG images. But, as you can see from the included code snippet, it is replacing the SVG content with a GIF. I’m asking you to correct it so that it doesn’t touch them.

Thanks