I sometimes embed graphics such as charts, graphs, cartoons, and other images in my posts. They are meant to appear in the body of the post and I check that they do before posting. But one reader Steve informs me that for him the graphic sometimes appears only as a link and he has to click on the link to see it which is, of course, a nuisance.
I use Safari on my Mac as my browser but Steve says he uses Chrome (on Fedora 22) as his browser. Some pages where he says this is an issue are (1) here, (2) here, and (3) here.
All three look fine to me on Safari. When I look at them on both Firefox and Chrome, for (1) both those browsers reveal the problem that Steve highlights but (2) and (3) appear to be fine.
Have any other readers experienced this problem and, even more importantly, can anyone suggest what might be causing it and how to prevent it?
Any assistance would be appreciated because I am baffled.
Using Chrome in Windows. (1) appeared as a link, (2) and (3) were inline.
On the first side you display the image differently than on the other two.
The last to uisplay the image with the standard HTML <IMG tag. The first one seems to you the google tags library ti display the image. It uses <meta property=”og:image” content=”http://freethoughtblogs.com/singham/files/2016/01/Iowa-clinton-lead.jpg”/> and a lot more to display it.
You should try to remember how you added the different images and what the difference are.
Firefox on Win7, same as Mano reports with Firefox and OSX Yosemite.
However, (1) appears inline on mobile safari on my iPhone running iOS 9.2 as well as safari on OSX. I took a cursory look at the source on both my Win and OSX machines -- the raw html displayed by the browsers is different for the same page source.
This suggests something in how wordpress is responding based upon the browser that is discovered from the HTTP request.
Firefox on Windows 8.1, and the first link I got the same as efogoto.
On Firefox, when I look at the source, the image (“Iowa-clinton-lead.jpg”) does not have “http:” at the beginning.
I had been wondering if it was just because your blog was receiving an incredibly enormous number of hits and couldn’t cope with the load.
Seems like every time I pop in, I’m genuinely the millionth visitor. Every time. (Well, not quite every time, because sometimes the FTB scripts just crash my 3-yr old tablet’s browser.)
Mano:
The reason that (1) fails to load in-line is because the article you linked to specifically is prepended by https://, which stands for the secure HTTP protocol. Because the embedded image in that Hillary article links to plain http (unsecured), many browsers such as Chrome block it from displaying.
A simple fix is to ensure that old posts you link to are linked without the https in the front. For example, clicking the first link will load the post and the image will NOT show up, but in the second one it will:
https://freethoughtblogs.com/singham/2016/01/13/clinton-worried-that-more-people-are-feeling-the-bern/
http://freethoughtblogs.com/singham/2016/01/13/clinton-worried-that-more-people-are-feeling-the-bern/
Note the difference between the two only lies in the protocol.
As #1, while using Firefox on Win7. Also, I have recently lost the ability to see Comedy Central videos along with a handful of other venues. I hear that X-forwarded-for is no longer the standard location identification method, but I don’t know how to get around whatever the new standard is. Does anyone else know?
Thanks that is very helpful!
Marshall, it looks like Chrome and Firefox automatically use the https protocol as the default. If I strip away the ‘s’, the problem goes away too. The catch is that it is not clear what I can do about it since I don’t determine the protocol for the url. (Or maybe I do and don’t know that I am doing so.)
How I embed graphics is by dragging them to my computer, giving the file a descriptive name and adjusting the size if necessary, and then uploading them onto the FtB site as a jpeg file or whatever format it came in. In some cases, it is a screenshot if the dragging doesn’t work. It was the same for all three cases and in none of them does the embedded code refer to the original link that I got it from.
So any ideas as to what I should do?
I’m using chrome. I can’t view the https page at all -- I get ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Having said that, when I saw the error I changed https to http and it opened, which wasn’t too arduous. That solution should also work for those that see the page with links rather than embedded images.
Mano,
I think Marshall at #7 has got to the nub of the matter.
It looks like Chrome does not want to render http urls for jpg & png when referenced from https pages.
I use the “https everywhere” Chrome extension to enforce security so my original report of the links 1, 2 & 3 all failed to render. When I now turn off “https everywhere” 1 fails but 2 & 3 render inline.
Steve
I’m having problems. I use Chrome, and I get a “broken link” that I have to click to view the GIF.
I’m having the problem as well. (Firefox on Win7) Also happens on Phyrangula. Changing to http doesn’t really work for me since I’m using EFF’s plug-in HTTPS-Everywhere which auto redirects to https.
I just discovered a built-in workaround for this in Firefox:
(1) At the left end of the address bar is an icon of a lock combined with an orange triangle with an exclamation mark. Click on it.
(2) In the drop down, click the arrow at the upper right edge.
(3) In the next panel click on ‘Disable protection for now’.
The page will reload, showing all the images.
The longterm fix for this problem is for your site admin to reconfigure your content management software to post the image links as https so there won’t be a security mismatch on the page.
Trickster @#14,
Yes, that seems to work.
Struck by your solution, I looked at Chrome and there you have to look at the right end of the address box where there is a grey shield next to the star. If you click on it and tell it to load unsafe scripts, then the image appears.
Unfortunately, it looks like there is nothing I can do at my end to solve the problem.
Mano,
It seems you are using WordPress for your site (or is that just something to do with my login?)
I found a WordPress plugin that will automatically clean up the insecure content on an https page:
SSL Insecure Content Fixer
They usually work for me. Don’t recall having too many problems here in that regard. If and when they don’t then I’ll almost always let you know in the comments section.
Yes, WordPress is the platform that FtB uses. Let me check with the gurus here about this fix.
Thanks!
I have no idea how easy or difficult this would be to do in WordPress but have you considered relative links? Those don’t require the full path in the HTML, they supply the link relative to the current location. So you would never be specifying http or https, it would be inherited from whatever protocol the visitor came in on.
Please ask your local gurus about this, my HTML coding is abysmal. 🙂
Hi Mano,
I don’t have enough time to look more deeply into this--I’m not that familiar with WordPress. But the problem is what’s called “mixed content,” where http and https are both being served. If you google “wordpress mixed content” you get a few hits. I believe that the media is fetched by a plugin/script that WordPress uses, and the plugin is either not updated or it’s not fixing the problem.
In Chrome, you can right click -> inspect element; that should open a developer tab to the right, which is tough to read if you’re not familiar with html/css/javascript, but it can lead you to the right track. On the bottom under “Console” you can see errors that occurred. If it helps, the exact problem that my browser is reporting is:
Using Firefox 43 for Linux Mint #1 is just a link to the graphic (I don’t see it as a big problem) and both #2 and 3 show the graphic. I don’t know why.