SLL padlock issue – Mixed content soft failure

I’m not seeing any mixed content issue on your home page. Is the issue with some other page of your site?

Hi Steve,

Mmm ok, how did you check for mixed content? I provided a link to it in the whynopadlock.com link above, can you not see it there? Thanks

I use the developer tools in Chrome.

In addition, I did a “view source” and searched for https://periago and found nothing.

in addition (again), See https://i.imgur.com/hwioSIu.png

• This reply was modified 4 years, 9 months ago by Steven Stern (sterndata).

ok thanks, I’m pretty sure that Chrome Dev or View Source isn’t conclusive, especially as the site displays a padlock on Chrome. I always use whyNopadlock.com as is it provides a deeper crawl and more reliable results.

https://www.whynopadlock.com/results/2ca8c012-9dfd-4ea7-96fd-ad0c60110352

• This reply was modified 4 years, 9 months ago by ??????????????.

As both Firefox and Chrome are happy with the site, I’d say that either whynopadlock is wrong or irrelevant.

Additionally, this is how Chrome displays the site on its mobile browser. I’ve found that Chrome is unreliable and very inconsistent for deducing SSL errors.

https://imgur.com/KhTsPxH

Please disable all caching/optimization plugins so we can look at the site in a “clean” form.

MOBILE! Aha. When I tell the inspector to use a mobile view, then it shows errors. For example,

/#welcome-to-periago-website-management:1 Mixed Content: The page at 'https://periago.com/#welcome-to-periago-website-management' was loaded over HTTPS, but requested an insecure image 'https://periago.com/wp-content/uploads/2020/04/free-prototype-background.jpg'. This content should also be served over HTTPS.

Check your CSS files as I suspect the https:// may be within one of your CSS files. Because I was using the “desktop” view, it was probably not used. So, this may be inside a @media block.

Caching purged and disabled on host server and cdn, plus put into maintenance mode on the cdn.

“Check your CSS files as I suspect the https:// may be within one of your CSS files. Because I was using the “desktop” view, it was probably not used. So, this may be inside a @media block.”

Thanks, you may be onto something there, let me go check…

With siteground optimizer enabled, it’s really hard to tell from here.

It is disabled, so is cloudflare.

@sterndata thanks for your help, much appreciated. It ended up being a weird caching issue due to the theme builder css files not regenerating when any changes were made. whynopadlock shows the site clean now and i’m having no issues. Its an old clunky site anyway so I need to redo it soon anyway but for now its fine.

Closed