Image
|
Using wiki Image Syntax [[image.jpg:pic|]] [[image.jpg:pic|]] hmmm, don’t seem to upload images onto the wiki backend via Forum posts. Using html img tag with google drive as a source….
nope. Doesn’t work. Using html tag with Imgur image as a source
Success! Conclusion |
|
You have to host the images somewhere yourself. |
|
you need a direct link to an image somewhere on the internet for images on Forums posts to work. Didn’t know you could do that. |
|
Unfortunately, given that mom’s second language was Spanish (French was third), Google frequently decided that “RISC OS” meant “RISCOS” which is “riscos” which is a word in Spanish nothing at all to do with anything I’m likely to be looking for… Not sure I’d want to live in a place called Under the cliffs! |
|
Not just cliffs its a volcano |
|
Ah, so the Canaries then? |
|
Good spot – just about here:- |
|
I’m trying to display a JPEG (I initially tried a PNG) of the latest issue of Archive in https://www.riscosopen.org/forum/forums/1/topics/16742 RISC OS Iris – success Anyone any insight? I’ve tried displaying it with exclamation marks (as in the Textfile reference) and I’ve tried with the img src tags, but Chrome never shows the image. Any insights? I’m at a loss, because it will display the image just fine when loaded directly. |
|
Is it a https:// thing? I seem to remember something about images stored on http:// sites getting blocked within https:// pages by some browsers. Where is the actual JPEG stored? |
|
@Gavin: Is your site configured to reject displaying images on other sites? Chrome is sending a Referer: https://www.riscosopen.org/ Might as well be best to use https:// prefix too so that both the site and image are using https. |
|
Yes, it’s Chrome. Google, the rapacious ad-flingers that will track you to the corners of the earth, is willy-waving about “security”. You are linking to an http image in an https page. It’s not going to let that happen. You’ll find, in time, other browsers will behave in a similar manner. Test proof:
(tested on Android Chrome) You should really move yourself to an https site. Enquire with your hosting provider if they work with Let’s Encrypt. If they want more than a one-off fiver for this, look for a more honest host. OVH, for instance, provides this for free, even with their £2.03/month plan. |
|
As Rick said, it’s an “HTTPS vs HTTP” issue. It isn’t necessarily the browser itself. Some add-ons (Ghostery appears to be one such) won’t allow HTTP images if the main page is HTTPS. |
|
No, it’s Chrome. On the desktop, you can click the padlock and somewhere in there is an “allow insecure content” option. On Android, it’s more complicated. You’d need to go into chrome://flags and search for “Secure”, I think the option you’ll want is “Insecure origins treated as secure”, but note that this applies to everything so it’s not wise to turn it on. Best approach – don’t mix content. Or if you do, don’t expect it to work on Chrome. ;-) |
|
Chrome itself may be the proximate reason in this case, but Ghostery definitely causes the problem as well. I don’t want anyone going away from this conversation with the idea that telling everyone “don’t use Chrome” is a full and complete solution to the problem, because it isn’t. |
|
That’s exactly what it was. The Archive’s website that I inherited has never had an SSL cert. The whole thing is being modernised and replaced for next month. For now, I’ve shoved the Archive image onto a different https site that I run. Success. Thanks everyone. |
|
Actually, I’m surprised it’s Chrome and not Safari that blocked the image. Apple seem hell-bent on this kind of stuff. |
|
The difference is that you make a conscious choice to install Ghostery, and you also made a choice to block insecure content (or didn’t bother to RTFM). It’s part of the “Smart Blocking” option. You can turn it off (or use the superior UBlock Origin).
It is a full and complete solution, just not to this problem. ;)
No, the solution here is “don’t mix content”. |