Resolved: Zemanta Editorial Assistant issues with https/SSL
One of the main reasons why I had left my admin panel open to server non-ssl requests was that Zemanta Editorial Assistant would not work properly behind HTTPS. I did some looking around and found that the same scripts were being sent over to the browser so I was at a loss of what was causing the issue. Pretty much everytime I worked on a post the “Content Recommendations”, “Related Articles”, “In-Text Links” and the “Tags” sections would be blank; They would show on screen but have no content on them. This pretty much render them useless. Because of that I couldn’t force myself to move to an SSL only WordPress backend.
Finally though I got tired of having to log-in every time I switched between the HTTPs and HTTP version of the site. I decided it was time to resolve this issue. I went in and digged through the HTML trying to understand what was going on: Was Zemanta not using https? Why is this not working.
To my dismay the answer was much simpler than I could had imagined. It turns out because Zemanta runs a script that is not part of this domain and does not travel via HTTPs, most browsers will block it. Take a look at Chrome for example:
Blocking this script made Zemanta unable to operate. This resulted as I mentioned on the different sections being present on the screen but unable to get content from the Zemanta servers.
The good news is just clicking on the Load unsafe script resolves the issue. Unfortunately neither Chrome or Firefox as far as I know let you chose which “unsafe” scripts to run. This could potentially present a security risk. I run my own WP install so I am assuming all the scripts I have are safe, but if you visit other sites you might have your doubts. It is even possible your site has been compromised and truly unsafe scripts are also being executed with scripts you want like Zemanta and there is no way to execute some and not all.