How to Resolve Mixed Content Warnings From WordPress

 I recently on my own encountered this issues on my wordpress site here we will learn some few tips to solve this issue. Mixed content warning creashed my wordpress site multiple times which bother me a lot and google it again and again but I didn’t get an accruate result that worked for me but finally I got my own method to work with this problem.

Option 1: View Source

This method is pretty simple. Load the page via HTTPS; right-click anywhere on the page; and click “View Page Source”, “View Source”, or “Source”, depending on your browser.
Then use the “Find” command (Edit -> Find or Ctrl+F or Cmd+F) and search for:

  • src=”http:

(with double-quote)

  • src=’http:

(with single-quote)
Long story short, you’re manually looking for images, scripts, iframes, and all other assets served via HTTP instead of HTTPS. If you don’t find any with either double- or single-quote HTTP:, then you’re all done with that page. Keep browsing to other HTTPS pages and keep searching through View Source.

Option 2: Use a Plugin

A couple plugins exist that essentially do the View Source for you:

  • WordPress HTTPS (SSL) (mentioned above too)
  • WordPress HTTPS Test
  • SSL Insecure Content Fixer

Basically, you browse your site via HTTPS with one of these plugins active, and the plugin displays notifications of the HTTP assets. Some plugins show the warnings for all visitors and some only display to Administrators so beware of leaving these sort of plugins active while you’re not testing.

Option 3: Paste the URL into a Website that Tests for Insecure Assets

If you don’t want to View Source and don’t want to enable a plugin (maybe because it displays to all visitors, not just administrators), then you could paste your page’s URL into a website that tests it for you.
WhyNoPadlock is a free testing site that provides you with a report of all the insecurely-loaded items. It provides an easy-to-understand list of green check marks or red x’s. Pay attention to the red x’s; fix them in your plugins or theme; and click the “Test URL Again” button to try and rid yourself of red x’s. Once done with that page, paste in a different URL to see if it’s also free from red x’s. Wash, Rinse, Repeat.

WordPress.com via WhyNoPadlock.com

Option 4: Use Google Chrome Inspector Console

Google Chrome’s Inspector has a Console tab. If the HTTPS page you’re displays yellow or red in the address bar (see 3rd and 4th icons below), open the Console to see the one or multiple insecure assets.

Chrome SSL Connection Icons and Explanations

How to Fix Insecurely-Loaded Assets

Make note of each item sourced via HTTP and you’ll get an idea where to find the problem. Here are some examples:

  • A plugin loading a JavaScript file via HTTP: http://example.com/wp-content/plugins/example-plugin/awesome.js
  • The active theme loading an insecure image file: http://example.com/wp-content/themes/example-theme/assets/images/circle.png
  • The active theme (most likely in functions.php, but it could be loaded via a plugin instead of the theme) loading Google fonts insecurely: http://fonts.googleapis.com/css?family=Lato:100,400,700
    • Notice even insecure assets from outside your WordPress installation throw browser errors.
Internet Explorer 9 “mixed content” warning for WordPress.com

What You Now Know

You now know that the plugin or theme you’re using isn’t coded properly. It may be a quick fix or need significant modification. Before working on fixing it, you have to ask yourself, “Do I really need this?” because if this is wrong, I bet other things are wrong. Sometimes an uninstall can be healthy.
If you decide the plugin or theme is worth keeping, start working to fix these errors.
You have a few options per asset:

  • Report the error to the plugin developer and leave deactivated for now.
  • Edit the plugin files yourself, sharing the fix with the plugin developer.
  • Change to a different theme
  • Edit the current theme’s files (hint: start looking in functions.php)

Personally, if a plugin throws WP_DEBUG errors, sets off security errors, or loads assets on pages where it doesn’t belong, I usually get rid of it altogether. If I have the time and the plugin is valuable enough, sometimes I report the error or even provide the fix, especially if the plugin author has enough credibility that I know this is an infrequent occurrence.

We’re almost done…

How to Change Assets from HTTP to HTTPS

After discovering the offending assets, you need to change them to either respect the protocol (i.e. serve HTTP when the page is HTTP and serve HTTPS when the page is HTTPS) or change them to always be served via HTTPS, even for pages loaded with the HTTP protocol. These 2 steps should cover all scenarios. You might only need Step 1 or Step 2 to resolve the insecure warning issues.

Step 1: Use Relative URLs

This is the simplest fix. If an asset (image, script, etc.) is hard-coded into a plugin or theme, change it from ‘http://site.com/assets/logo.png’ to ‘//site.com/assets/logo.png’.
Typically, this is most useful when including assets from other servers, like Google scripts, API scripts, or iframes.
Before doing this, however, you need to make sure the HTTPS version is available. If loading an asset from a site that doesn’t have HTTPS enabled, it’s probably best to remove the reference entirely (i.e. comment out or delete) or to save the asset to your own server and change the source to load via your site instead.

Step 2: Use Proper WordPress Coding Standards

This issue is a bit more complicated. I’ve seen all kinds of things, like:

  • Code that forces HTTP (why?!)
  • Using deprecated WordPress functions that don’t respect SSL settings
  • Code that tries (and fails) to implement its own “if is HTTPS” logic instead of using the WordPress functions

Each of these types of errors could take some time to resolve. Here are some helpful WordPress functions that may need to be used instead of the current code:

  • home_url() and related functions
  • is_ssl()
  • WordPress Function Reference (stay away from the ones in red; they are deprecated)
  • WP_DEBUG might help too

Leave a Comment