I have a QR code image that's embedded from the Google Charts API. Recently it stopped working, but I haven't changed anything in my code.
Here's the page (note the broken images): [redacted]
As you can see, the images are embedded as http:// but when they are loaded, they're redirecting to the https:// URL on the google domain, which is broken.
Why is this redirect happening?
Edit: forgot to add -- what's even stranger is that if you view the image in a new tab, then change http to https (in effect, making the url the exact one that was originally requested),
it loads fine.
Edit #2 removed the link to my test site, as I've fixed the problem.
Turns out the google charts domain has changed. The new one is:
https://chart.googleapis.com
do not use
http://chart.apis.google.com
Related
I'm building a webapp that I want to use on a FireTV browser (Firefox) and when I do so, my Facebook images are appearing as broken links.
The images appear normally on all other devices/browsers I've tested (multiple on OSX, Android)
Initially I thought the the firetv browser wasn't liking hot-linked images for some reason as I'm loading them via the graph API, however I'm able to get images hotlinked from other sites to show up just fine on the fireTV as well.... It seems to be something specific about the facebook URLs it doesn't like? Does anyone have any ideas, or know of any tools to help debug it better?
This is what the img elements look like that I'm rendering, for example:
<img src="https://graph.facebook.com/v2.6/112816289586034/picture?type=large" />
Facebook Graph API returns a profile photo URL with a 302 redirect, which apparently is not Amazon FireTV friendly.
The solution was to include redirect=false as a url parameter on the API request, which causes FB to return a JSON object including regular image url that loads as expected.
I just added an OpenGraph image to a site I'm working on and using the FB Debugger the info retrieves the correct image, however when sharing the url I still see default images being displayed (there was no specified OG image before). Is there something I'm missing here? The site uses a custom Python based framework and image is served via gzip from an Amazon EC2 instance, if that would affect the output in any way.
The problem is not with your website.
Facebook takes some time to refresh images inside facebook.com even though you can see the changes on Facebook Debug Tool.
In order to view your new image inside Facebook you can do two things:
Manipulate a little the URL you are trying to share, this way
Facebook will fetch the open graph data again.
Just give it some
time, it will be refreshed after a few hours.
There are three way to change your image you need to clear the
1) Manually clear facebook catch using the https://developers.facebook.com/tools/debug/ facebook tool
2) Add version code end of the url like ?v=1
3) write the GraphAPI code from when you click on the share button it will clear the facebook page cache.
I have tried to set my site up ( http://www.diablo3values.com )according to the guidelines set out here : https://developers.google.com/webmasters/ajax-crawling/ However, it appears that Google has updated their indexes (because I see the revisions to the meta description tags) but the ajax content does not show up in the index.
I am trying to use the “Handle pages without hash fragments” option.
If you view either of the following:
http://www.diablo3values.com/?_escaped_fragment_=
http://www.diablo3values.com/about?_escaped_fragment_=
you will correctly see the HTML snap shot with my content. (those are the two pages I an most concerned about).
Any Ideas? Am I doing something wrong? How do you get google to correclty recognize the tag.
I'm typing this as an answer, since it got a little to long to be a comment.
First of all, your links seems to point to localhost:8080/about, and not /about, which probably is why google doesn't index it in the first place.
Second, here's my experience with pushstate urls and Google AJAX crawling:
My experience is that ajax crawling with pushstate urls is handled a little differently by google than with hashbang urls. Since google won't know that your url is a pushstate url (since it looks just like a regular url), you need to add <meta name="fragment" content="!"> to all your pages, not only the "root" page. And google doesn't seem to know that the pages are part of the same application, so it treats every page as a separate Ajax application. So the Google bot will never actually create a navigation structure inside _escaped_fragment_, like _escaped_fragment_=/about, as it would with a hashbang url (#!/about). Instead, it will request /about?_escaped_fragment_= (which you aparently already have set up). This goes for all your "deep links". Instead of /?_escaped_fragment_=/thelink, google will always request /thelink?_escaped_fragment_=.
But as said initially, the reason it doesn't work for you is probably because you have localhost:8080 urls in your _escaped_fragment_ generated html.
Googlebot only knows to crawl the escaped fragment if your urls conform to the hash bang standard. As users navigate your site, your urls need to be:
http://www.diablo3values.com/
http://www.diablo3values.com/#!contact
http://www.diablo3values.com/#!about
Googlebot actually needs to see these urls in the source code so that it can follow them. Then it knows to download the following urls:
http://www.diablo3values.com/?_escaped_fragment=contact
http://www.diablo3values.com/?_escaped_fragment=about
On your site you appear to be loading a new page on each click, and then loading the content of each page via AJAX too. This is not how I would expect an AJAX site to work. Usually the purpose of using AJAX is so that the user never has to load a whole new page. When the user clicks, the new content section is loaded and inserted into the page. You serve the navigation once and then you only serve escaped fragments of the content.
We recently moved servers and I've been having this problem since.
I tried parsing this url1 in the Facebook Debug tool, and the thumbnail retrieved using the content of the og:image tag is displayed fine, but it won't display when I 'like' the story and it appears in my profile . This was a story posted before switching servers.
Now when I try parsing this url2 in the Facebook Debug tool, the thumbnail is not retrieved and with previous case the thumbnail won't display in my profile when I like this story. This is a story posted after switching servers.
The funny thing I try repeating these actions and the thumbnail does pop up randomly.
How does Facebook retrieve the image from my server? Does the problem have something to do with how this is done?
At one point, I thought FB would not show a thumbnail on a second post. Or something. It seemed to show the thumbnail again, if I changed the URL a bit (put some fake parameters in the url).
YMMV
Remove every og meta tags from the page, debug it into the facebook debugger tool, when it shows nothing, put the correct og meta tags again and debug again with facebok debugger tool.
This is a weird problem with facebook. It caches the old incorrect values sometimes.
I've found the page that plain http images with a https/ssl page can't be displayed without warnings. Are there any way to display a picture from another http:// web-site on your https://web-site without warnings? (suppose you have a permission to display that picture on you web-site).
Chrome put a yellow triangle on SSL locker: "...However, this page includes other resources, that are not secure..."
IE displays a warning when a page loads: "Do you want to view only the webpage content that was delivered securely?"
So, how to display a picture on https:// page if it is on another web-server?
You can use the information on this article on Encosia. Basically you have to use a // syntax for your urls in order to use the same protocol in all cases. For example, if you have a https request, the following
//ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js
will hit google's CDN using the https protocol. However, if you don't have control over the other server, i think you're out of luck. If you do have control over the other server i'd recommend using the method described in the article above by allowing your content server to serve both protocols.