Now that Global Voices is going HTTPS-only we have a new problem that will crop up: HTTPS errors and warnings.
Note: This page is for background on the subject and to help GV users self-diagnose problems and solve them without having to wait for a solution from GV Tech. At any time if you see a mixed content error and can't fix it please contact GV Tech and ask for help. As always please include all relevant URLs, a description of the problem, and a screenshot of possible. Hopefully you can avoid all that work by learning the basics (below) and taking care of mixed content errors yourselves.
What are HTTPS Warnings
Whenever any of the files on a secure page are loaded insecurely you get a mixed content error, because there was non HTTPS files mixed into an HTTPS site.
Often the site will work fine despite the mixed content, and the only effect is that the little lock icon in the browser's address bar is yellow (warning) instead of green (all-OK). On some browsers mixed content can generate big annoying errors though, and depending on the content it can totally break features of the site like video embeds.
It is always better to have a fully secure site because we want true privacy for our visitors, we want the green lock icon so they have confidence in us and we want to avoid any bugs that could result from insecure files being blocked.
Fixing mixed content errors
Usually objects causing mixed content errors are either images or media embeds that use URLs that are HTTP instead of HTTPS. Objects loaded from within GV (CSS/JS/uploads) should automatically have their URLs converted by WordPress into HTTPS format, but we can't do that with objects from other sites because they would be broken if the site of origin doesn't support HTTPS.
When you find an object being loaded over HTTP (which makes the address bar lock icon yellow instead of green) the solution is to edit the post/page/widget/etc. that links to the object and change the link to be HTTPS instead of HTTP.
This may or may not work, depending on how the domain you link to is set up, but often it will work because HTTPS is becomming so common.
Unfixable errors on domains that don't support HTTPS
If the domain doesn't support HTTPS at all (e.g. a problem we have with embeds from PRI) then the image/embed will break for visitors when you switch it from HTTP to HTTPS.
If this happens the best option is to find a way to re-embed the content inside our site.
Images are easiest because you can just download then re-upload the image in WordPress, then embed our version. This is what you should be doing anyway for other reasons!
Video and other complex embeds are less simple, since norms about re-publishing video are less forgiving (i.e. copyright) and the technical challenges are significant (we would use YouTube for it anyway). Ultimately if you need to embed a player from a site that doesn't support HTTPS you have to choose between embedding it insecurely, making that one post insecure (not the end of the world) or not embedding it in it's current format.
If you choose not to use an insecure embed the best fallback is to take a screenshot of the embed, upload it and insert the image where the embed would be, with the image linking to the object on it's source site. This will “trick” visitors into thinking the embed is on our post without spoiling the security status of our site.
Identifying insecure content with “Secure or Not”
When you see the yellow lock icon it can be hard to find the object causing it. The easiest way (that I can find) is this Chrome plugin:
“Secure Or Not” on Google Play
It adds a “?” icon in the top right your Chrome toolbar that you press to highlight any insecure objects or links in red (secure links and objects are outlined in green).
So if you see the main lock icon in the address is yellow (i.e. there is insecure content being loaded on the page) you would click the Secure or Not button to highlight all items, then scroll through the page looking for something outlined in red.
If you find something in your post outlined in red, fix it as described above. If you still can't find anything, contact GV Tech for further investigation (with a URL, and screenshot if at all possible!)
Identifying insecure content with basic Chrome
The harder way (that doesn't require any special extensions) is to use Chrome Developer Tools to review the specific errors. It works better than the extension because it gives you lots of information, but also requires you to look at a lot of data before you find the real problem.
In the Chrome menu choose View > Developer > Developer Tools, which should pop up a sub-window at the bottom of your tab. Once the Developer Tools are visible push the Escape key to bring up the Console, which lists any warnings during the current pageload. Initially the console log will be empty, but Reload the page to re-generate the errors that are causing the lock icon to be yellow.
If you've got the Developer Tools and Console open on a page with mixed content errors it should look something like this:
The specific errors show on a yellow background, and are useful because they come with a ton of information about the page that loaded the insecure object, the object's URL etc.
For most people getting to this point and interpreting the results may be more complicated than they are willing to deal with, but it's the most direct way to analyze mixed content warnings and including a screenshot of this output with any reports to GV Tech could really speed up the process of identifying the problem and fixing it.