Failure rendering image tags

[William]

Hi,

I’m having an issue in Umbraco 13.9.2 where the image tags of published pages are either not rendering at all or the src attribute is missing. I see no error messages in Umbraco’s logs related to this. However, the media files are visible in the backoffice UI and I am able to access the media by inputting the URLs directly.

The ImageSharp cache is stored along with the media files in Azure Blob Storage. When refreshing the page I see many ImageSharp logs of the below type, so seemingly we are attempting to retreive the images?

Sending image. Request uri: ‘“https://new.contoso.com/media/fs2jwqsn/logo_black-1.png?rmode=max&width=500&v=1dc134315938c00”’. Cached Key: ‘“45e9d56fb69b”’

So far I have tried:

• Deleting the entire cache folder in Azure Blob Storage
• Restarting the application
• Rebuilding examine indexes

The site is hosted on Azure Web Apps and we have two slots using the same media and cache in the blob storage.

[greystate (Chriztian Steinmeier)]

Hi William,

How are you rendering the images from your templates/partials?

/Chriztian

[Luuk (Luuk Peters (Proud Nerds))]

Is there maybe a middleware that’s messing with the images during the rendering to the frontend maybe?

[William]

@greystate @Luuk
Thank you for pointing me in the right direction! Below is an excerpt from a partial for one of the widgets that is meant to display logos.

I suspect the lazyloading could cause the issues but I haven’t been able to figure out why…

@ {
    var content = (ContentModels.Logos)Model.Content;
}

<div class="block__body">
    <div class="@(containerWidthClass)">
        <div class="row row--center">
            <div class="col-100">
                @if (content.LogoItems != null)
                {
                    <ul class="logos @(blackWhiteClass)">
                        @foreach (var logo in content.LogoItems)
                        {
                            var logoContent = (ContentModels.Logo)logo.Content;

                            if (logoContent.LogoImage != null)
                            {
                                <li style="width: @(logoContent.CustomWidth == "" ? "120px" : logoContent.CustomWidth)">
                                    @if (logoContent.Link != null)
                                    {
                                        <a href="@(logoContent.Link.Url)" target="@(logoContent.Link.Target)" title="@(logoContent.Link.Name)"><img class="lazyload" data-src="@logoContent.LogoImage.Url()" alt="@logoContent.LogoImage.GetImageAltTextWithFallback(currentCulture)"></a>
                                    }
                                    else
                                    {
                                        <div><img class="lazyload" data-src="@logoContent.LogoImage.Url()" alt="@logoContent.LogoImage.GetImageAltTextWithFallback(currentCulture)"></div>
                                    }
                                </li>
                            }
                        }
                    </ul>
                }
            </div>
        </div>
    </div>
</div>

Here’s how it’s rendered:

<section class="block logos white-bg block--compact in-view">
    <div class="block__body">
        <div class="container container--big">
            <div class="row row--center">
                <div class="col-100">
                        <ul class="logos black-and-white">
                        </ul>
                </div>
            </div>
        </div>
    </div>
</section>

And here’s the content:

[greystate (Chriztian Steinmeier)]

Yeah, I would point to the lazy loading as well - but if you’re seeing the ImageSharp requests in the logs, it’s not because of the JavaScript failing (which would have been the most probable reason); try this:

Instead of data-src="", use the real src attribute, and instead of class="lazyload", use the native loading="lazy" attribute - this uses the browser’s native lazy-loading (if supported) and will tell you immediately if the images are actually rendered, or if something else is wrong.

/Chriztian

[William]

Changing the lazy-loading method and using src instead of data-src did not help.

At the same time I added some logging which shows that logoContent.LogoImage is null. Any idea why this might happen? Note that we are able to retreive and display the same media in the backoffice.

[William]

I think I found a workaround. If I go to the backoffice > media and scroll through all the pages such that all images are loaded at least once, the images load correctly in the published pages as well.

But if I then visit the URL of the test slot in Azure Web Apps (which share the same database and media/cache storage). The images break on the main slot again.

[cheeseytoastie (Steve Morgan)]

When this happens if you view the source of the page (right click) and then look are the image tags populated or the src fields empty?

If they all have image urls then it’s unlikely to be the lazyloading in javascript / front end. If they look fine then my suggestion would be to run without lazyload for a bit to see if it solves the issue then you know js is failing (e.g. just replace data-src with src and remove the lazyload class.

If they look empty / weird then my guess would be an issue with the Umbraco cache. This can be caused by having multiple web apps pointing at the same DB, scaling / incorrect load balancing setup or something weird in the setup of hosting. If you’re finding it’s fine following a release then you see errors in the logs after a while I’d suspect it’s something along these lines. Do you use separate DBs for dev / live / uat etc?

Do you have both packages to correctly use the azure media with a cache?

Umbraco.StorageProviders.AzureBlob

Umbraco.StorageProviders.AzureBlob.ImageSharp

Luuk pointed me in this direction which has solved some issues I had in a v13 project that was upgraded from v10 and I’d not added this extra package….

Umbraco v 13 - Azure load balanced site down - how to kill Azure SQL Connections

Hi Jason - thanks for the reply. The SQL DB is a Standard S6 - 400DTUs There are two load balanced web apps (we scale this out in busy times) HaWebv1020231005091658Plan (P2v3: 2) I would hope with the Azure costs involved with these that this is ample to startup a website!! I hate trying to get to the logs of these load balanced sites - I’ll have a better look today but I did a copy with a clone of the DB and a single webapp and it was 4 minutes. It think it’s strongly pointing at an issue …

My only other thought is you’ve posted the log which says sending image with the request uri https://new.contoso.com/ as the domain - do you have the UmbracoApplicationUrl correctly set in the appsettings.json seen Azure do weird things with routing if it starts up and is hit on one url and then serves on a different one.

HTH

Steve

[cheeseytoastie (Steve Morgan)]

@William

But if I then visit the URL of the test slot in Azure Web Apps (which share the same database and media/cache storage). The images break on the main slot again.

Ah - this does point to me to the application url!

[William]

@cheeseytoastie

My only other thought is you’ve posted the log which says sending image with the request uri https://new.contoso.com/ as the domain - do you have the UmbracoApplicationUrl correctly set in the appsettings.json seen Azure do weird things with routing if it starts up and is hit on one url and then serves on a different one.

@cheeseytoastie Thanks for this! We did not have a value set in UmbracoApplicationUrl so I added this for both slots. It works for now but I will let a few deploys happen before I mark this as the solution.

I tried finding out how UmbracoApplicationUrl relates to media by reading some of the Umbraco v13 source code without learning much. But I found the below comment about what happens when you don’t set UmbracoApplicationUrl explicitly:

public void EnsureApplicationMainUrl(Uri? currentApplicationUrl)
{
    // Fixme: This causes problems with site swap on azure because azure pre-warms a site by calling into `localhost` and when it does that
    // it changes the URL to `localhost:80` which actually doesn't work for pinging itself, it only works internally in Azure. The ironic part
    // about this is that this is here specifically for the slot swap scenario https://issues.umbraco.org/issue/U4-10626
    ...

Note that in my case I didn’t do any swap. The problem arose after deploy to the test slot (maybe staging slot is a better description).

The above comment was written by @bergmania in this commit. As a long shot,@bergmania , do you have any input on this thread?

[cheeseytoastie (Steve Morgan)]

Here’s what I think happens…

If that application url isn’t set then the first domain used to access Umbraco is what is used for the absolute url code. So anytime you generate a full url (be it media or otherwise) it uses that domain. So if you spin up a new instance in a release on a deployment slot say- then swap it with production you will get the invalid domain…. if the application url is set then it uses that so it’s happy days no matter what slot it’s created in.

Would that explain your issues and why you’ve struggled to reliably recreate?

Steve

[William]

I don’t think the specific scenario you’re describing is what happens in my case since I didn’t need to swap the slots for the media generation to fail on the user facing pages.

[cheeseytoastie (Steve Morgan)]

Can be “warming” on deployment. For example if I deploy from Visual Studio publish it hits the Azure hidden url rather than my domain.

Depends on how you deploy of course.

[bergmania (Bjarke Berg)]

To me it also sounds like the Application Url
And in case you have a site with multiple domains maybe look into Site Domain Mapper

Outbound request pipeline | Umbraco CMS