We often see that after a site administrator has secured their site under the HTTPS protocol, some of their styling, assets and external calls fail to load. This is actually normal for modern browsers. In an effort, to help to secure the common visitor’s website interactions, browsers are forcing non-HTTPS calls to fail as these insecure calls can be exploited and compromise the site visitors connection to the site.
Later editions of Google, Mozilla Firefox, Safari, IE, and Edge will all deny HTTP calls when the site is being forced to load over HTTPS by the site administrator. In the image below you can see that the Mozilla Firefox browser is blocking the HTTP connection attempt.
Note: This is a good thing! We don’t want the site visitors to be compromised leaving the site owner liable for any damages. It would be better for the visitor to leave thinking that the site is under maintenance than for them to have their information stolen!
The most commonplace instance of our interactions with mixed content errors comes from CMS applications like WordPress. These applications are fully capable of handling HTTPS calls but if they are built initially with HTTP calls in practice, there may be hardcoded HTTP calls that are still in use for CSS styling, image calls, or external calls from plugins or themes.
For these instances using plugins like WordPress HTTPS (SSL) and Really Simple SSL can come in handy. You can also use WordPress’s native features to modify the hardcoded HTTP calls, implement redirects through .htaccess or web.config, and WordPress values wp-admin dashboard under ‘General Settings’ to use the SSL options where applicable.
For custom-built applications, you will need to identify where in your site code anchors are referencing HTTP content and update those calls specifically to utilize HTTPS for the content to load correctly.