I setup in my wordpress blog OpenGraph. For image I insert this code (wordpress):
http://dl.dropbox.com/u/21385868/codeog.jpg
the result in site page (html is):
http://dl.dropbox.com/u/21385868/resog.jpg
if I share article on the facebook, image don't appear. But, if I disable my cdn, image appear on the facebook.
What is the problem?
In Advanced CDN settings add to Rejected User Agents
FacebookExternalHit/1.1
FacebookExternalHit/1.0
Facebook blocks images that are hosted on CDNs.
Related
When I add the embedded video link, I am facing this error.
I in the video I shared on Vimeo, I chose the option "Let only the allowed sites be able to embed". Then I added my own heroku site here. For ex:
my-site.herokuapp.com
herokuapp.com
heroku.com
Normally the video should start playing on my site. But it didn't work. Can you help?
How can I solve it?
Privacy : Hide from Vimeo
Embed : Specific domains
You can try multi steps:
1 - Add this attribute to iframe tag <iframe ...referrerpolicy="strict-origin"></iframe>
2 - change the cookie policy, located under "Shields" > "Cookie Control", to "Allow all Cookies".
3 - Try different browsers to check if this is related to your browser and delete your cookies
I have an issue with Woocommerce on my site when I enable AWS Cloudfront CDN to speed up the site.
The site is hosted on an AWS EC2 Bitnami instance. No parts of the site are hosted in S3.
When Cloudfront is enabled and I add a product to the cart then press the “Proceed To Checkout” button from the shopping-cart, nothing happens, the browser just loads the shopping-cart page again. If I disable Cloudfront in the AWS for WordPress plugin then it works as expected and opens the checkout page. This happens in all browsers.
Also, if I update the quantity to add extra options then the shopping-cart page reloads with a message of "Your basket is empty". The cart icon still has a "1" against it, and when I press it the shopping-cart page comes back witht the item in place, but I have the same issue when pressing the “Proceed To Checkout” button.
Looking at the developer tools in the browser there are no indicators of any errors. This seems to be some caching or cookie issue.
I have a a Cloudfront policy that has Origin, Access-Control-Request-Method and Access-Control-Request-Headers whitelisted in headers to resolve CORS issues with font files This works as expected and the fonts load correctly, before this was in place font icons would not display and I'd get lots of 404 errors.
Following some answers from this Cloudfront + Woocommerce - cart not updating SO post I tried whitelisting all cookies, and whitelisting jsut wp_woocommerce_session_* which I added while debugging this issue. Neither of these options made any difference.
The only way I can get it to work is by disabling Cloudfront. The site is slow to load without it though and SEO results are compromised.
Any idea what settings I need to change in order to get this to work?
In the end I ditched the official AWS plugin, and used another (free) AWS CDN specific plugin that did all the configuration and worked out of the box.
We have a problem when users update the og:image for an article.
The Open Graph Debugger picks up the new image, and our CMS triggers a scrape using the API endpoint documented here.
But for existing shares, Facebook renders a placeholder and doesn't update to the new og:image URL. Which means if the original image is deleted in our CMS, Facebook shows a blank placeholder:
Facebook's documentation says:
You can always edit an object's properties, with two exceptions:
Title: Once 50 actions (likes, shares and comments) have been associated with an object, you won't be able to update its title
Type: An object's type can't be changed once it's been used in a story
If you want to update an image for an object, we strongly suggest that the URL to the image be different than the original image URL. Caching may prevent the image from being updated.
Images uploaded to our CMS always have unique filenames, and are served from an Amazon S3 bucket via Cloudflare.
If we don't delete the original image from our server, in existing shares Facebook continues to use the original in spite of the og:image changing and us telling FB to re-scrape the URL.
How can we get the image to update?
Twitter and Linkedin do not have a problem as they appear to cache the original image on their servers, so once we delete the file they continue to serve the original og:image. That's fine - but Facebook needs to show an image.
Try ?v=2 at the end of og:image url.
I was trying to find this on facebook's site in their documentation but so far no luck. I'm sure others must have run into this before.
I use Amazon S3 for storing images. I didn't know ahead of time that if I named my bucket as my domain name with subdomain I could link that way, so until I move all of the pictures I have to link to mybucket.s3.amazonaws.com domain. When I include a picture from there with a post to the wall the picture doesn't show up. If I change the picture to one on the server itself the picture does show up. It seems that the domain name of the picture must match my app? I looked at bugzilla and didn't see this mentioned. Facebook's forum says to post questions here.
I'm using the C# Facebook SDK from CodePlex.
My code looks like (with error handling and authentication check removed):
var client = new FacebookClient(FACEBOOK_APP_ID, FACEBOOK_SECRET);
client.AccessToken = facebook.AccessToken;
var parameters = new Dictionary<string, object>();
parameters.Add("name", name);
parameters.Add("caption", title);
parameters.Add("message", message);
parameters.Add("link", link);
parameters.Add("source", link);
parameters.Add("picture", imageUrl);
client.Post("me/feed", parameters);
I verified that imageUrl does indeed have a correct picture, the domain name just doesn't match. The picture on amazon s3 has public read access. I can view it from my browser so I don't think it's a permission problem. I've tried a few different pictures with the same problem. Only time it's worked so far is when the picture was on the server itself.
So, my question is, is it a problem with me, or does facebook block images that don't match the domain name specified on the app?
You can upload the picture from that url, then add its object id in the post.
Refer to: http://developers.facebook.com/blog/post/526/?ref=nf
Uploading Photos to the Graph API via a URL
Earlier this year, we released support for uploading photos directly
via the Graph API. This requires sending the photo as a MIME-encoded
form field. We are now enhancing our photo upload capability by
introducing the ability to upload photos simply by providing a URL to
the image. This simplifies photo management for a number of use cases:
App developers who host their images on Amazon S3 or a similar
service can pass the S3 URL directly to Facebook without having to
download the file to their application servers only to upload it
again to Facebook. This improves performance and reduces costs for
developers.
Apps written on platforms that don't have good support for
multipart file uploads can create new photos more easily.
To upload a photo via a URL, simply issue an HTTP POST to
ALBUM_ID/photos with the url field set to the URL of the photo you
wish to upload. You need the publish_stream permission to perform this
operation. You can also include an optional message parameter to set a
caption for the photo.
I'am facing the same issue as well. Based on my observations it seems that facebook does not like it when the picture url has more than one sub-domain.
I tried the below 2 URL variations for the same image..
mybucket.s3.amazonaws.com - throws an error
s3.amazonaws.com/mybucket - works fine
:picture => 'http://mybucket.s3.amazonaws.com/footprints/15/coverimgs/medium.jpg'
OAuthException: (#100) picture URL is not properly formatted
:picture => 'http://s3.amazonaws.com/mybucket/footprints/15/coverimgs/medium.jpg'
{"id"=>"587472956_10150280873767957"}
Now i have to figure out how to change the URL structure for the image while passing it to the FB graph API.
I would log it as a bug. If this is really the case, which I kinda doubt, you could create a 301 redirect on your own domain for each image that redirects to the Amazon url.
The Twitter API returns this value for the Twitter account 'image_url':
http://a1.twimg.com/profile_images/75075164/twitter_bird_profile_bigger.png
In my Twitter client webapp, I am considering hotlinking the HTTPS version of avatars which is hosted on Amazon S3 : https://s3.amazonaws.com/twitter_production/profile_images/75075164/twitter_bird_profile_bigger.png
Any best practices which would discourage me from doing this ? Do 3rd party Twitter client applications typically host their own copies of avatars ?
EDIT: To clarify, I need to use HTTPS for images because my webapp will use a HTTPS connection and I don't want my users to get security warnings from their browser about the page containing some content which is not authenticated. For example, Firefox is known to complain about mixed http/https content.
My problem is to figure out whether or not hotlinking the https URLs is forbidden by Twitter, since these URLs are not "public" from their API. I got them by analyzing their web client HTML source when connected to my Twitter account in HTTPS.
Are you thinking of storing the image URL in your application or retrieving it for the user as it is required?
If its the latter option then I don't see an issue with hot-linking the images. If you are storing the location of the image url in your own system then I see you having broken links whenever the images change (I'm sure they will change the URLs at some point in the future).
Edit
Ok, now i see your dilemma. I've looked through the API docs and there doesnt seem to be too much in terms of being able to get images served in HTTPS or getting the URL of the Amazon S3 image. You could possibly write a handler on your own server that would essentially cache & re-serve the HTTP image as HTTPS however thats a bit of un-neccesary load on your servers. Short of that I haven't come across a better solution. GL
the things seems updated since that.
Please check: https://dev.twitter.com/docs/user-profile-images-and-banners
The SSL-enabled path template for a profile image is indicated in the profile_image_url_https. The table above demonstrates how to apply the same variant selection techniques to SSL-based images.
Why would you want to copy the image to your own webspace? This will increase your bandwidth cost and you get cache consistency issues.
Use the URL that the API gives you.
I can see that you may want to cache the URL that the API returns for some time in order to reduce the amount of API calls.
If you are writing something like an iPhone app, it makes sense to cache the image locally (on the phone), in order to avoid web traffic altogether, but replacing one URL with another URL should not make a difference (assuming that the Twitter image server works reliably).
Why do you want HTTPS?