I am using Facebook Comments plugin in my website:
http://developers.facebook.com/docs/reference/plugins/comments/
by add this to my web :
<div class="fb-comments" data-href="http://example.com" data-num-posts="2" data-width="470"></div>
And i want to use it also in my android app, Can i use Facebook API or something else that i can make a comment on a URL without using the Comment plug-in.
Its impossible but comment plugin will show mobile version automatically for mobile devices
The mobile version will automatically show up when a mobile device
user agent is detected. You can turn this behavior off by setting the
mobile parameter to false. Please note: the mobile version ignores the
width parameter, and instead has a fluid width of 100% in order to
resize well in portrait/landscape switching situations. You may need
to adjust your CSS for your mobile site to take advantage of this
behavior. If preferred, you can still control the width via a
container element.
You can use the Graph API with stream_publish permission from the user in order to publish comments on their behalf. You can read the following docs to see how that works:
https://developers.facebook.com/docs/reference/api/post/#comments
Related
Note : read both answers below, thery helped us.
Original question:
Want to show appropriate deep link : http://en.wikipedia.org/wiki/Mobile_deep_linking so if android and no our app installed : show android app link, else html page link
App sends email to users. Want to be able to change links depending on device. If desktop - as is. If mobile go thru mail body and add "m." to all the href OR other link if our native app installed.
Do mobile mail clients run js?
Do I need to encode the js in anyway. Tried google but not able to get the right keywords to search for. End up on page about send grid or using js to send an email.
I want js inside email body. I know can change template at server, but want it to be dynamic to current client. So same email opened on desktop -> desktop links ; inside mobile app or browser - mobile links.
Or other html solution would be cool. W3 are you listening?
You can show/hide links depending on device using media queries. Try this:
<style>
#media only screen and (max-device-width: 500px) {
a[class=mobileLink] {
display: inline !important;
font-size: 24px !important;
}
a[class=desktopLink] {
display: none !important;
}
}
</style>
<!-- Starting link switching technique -->
HTML page link
<a href="link/for/mobile/version" class="mobileLink" style="display:none;
font-size:0px">Mobile page link</a>
<!-- End link switching technique -->
Yes, Outlook ignores display:none but if the link is just text, font-size:0px should take care that.
Want to show appropriate deep link : http://en.wikipedia.org/wiki/Mobile_deep_linking so if android and no our app installed : show android app link, else html page link
This cannot be done in emails, but it can be done in landing pages, like the web version of your email.
App sends email to users. Want to be able to change links depending on device. If desktop - as is. If mobile go thru mail body and add "m." to all the href OR other link if our native app installed.
This can be done by using media queries to hide/show desktop or mobile content when appropriate. (Responsive emails.)
Do mobile mail clients run js?
No -- security issues.
Do I need to encode the js in anyway. Tried google but not able to get the right keywords to search for. End up on page about send grid or using js to send an email.
There's nothing you can do to get JS to work in email clients. It just won't work.
I want js inside email body. I know can change template at server, but want it to be dynamic to current client. So same email opened on desktop -> desktop links ; inside mobile app or browser - mobile links.
Once again, this can be done using media queries. (Responsive emails.) There are some drawbacks, but I suggest doing a Google search for "Responsive Emails" to get started.
Or other html solution would be cool. W3 are you listening?
There's nothing they can do in the email world. Unlike web browsers, where there are set standards, in the email world, anything goes.
Edit: Although using media queries to show the appropriate link/button for the devices, it's not a bulletproof solution. The best solution is to use your web server's power to determine where the user should go, depending on their user agent or viewport size.
There is a more modern solution, that is supported natively by mobile platforms.
On ios it's called universal links and on Android app links.
When going to the set up pages for all the Social Plugins, they now provide example code using an APP ID.
http://developers.facebook.com/docs/plugins/
Is an APP ID now required for the Like Button and other plugins? What happens if an APP ID is not included when using the plugins?
I've checked the Facebook developer blog and read about the Like Button Migration. I haven't been able to find a straight answer for this either there or in the FB Like Reference.
Notice:
This is an old dated information, the official facebook's behaviors are changed.
Simply, the answer is No, just look at the following official Facebook resource.
Notice: To do it without need to the app id, you have to visit the above page when you are signed out from Facebook. Look at the following screen shot.
As semsem said, the simple answer is "no it is not required"... there are ways to get around having an appId associated with the "like" button. Here's my experience working with this. I'm not a Facebook or Open Graph expert, so YMMV.
Why we avoided using the appId on the button:
We're providing an service where we have one website (the engine, as it were) that provides a service distributing online courses to students (customers). Instructors (also customers) who what to use our service to disseminate courses to students can brand the site how they wish, and map their domain to their section of our website that serves those course(s).
As a simplified example: we serve from http://courses.example.com/instructor_name, but we want students to access the content through http://www.instructors-domain.com/. Any courses would be sub-directories off the base URL.
Associating the "like" button with our Facebook App disallows any cross domain shenanigans. While there are valid reasons for doing so, it doesn't work for where we're at in our company and product evolution. So we needed to find a workaround.
We wanted to allow folks to "like" a course, have the "story" point to the appropriate places on the net, as well as get some customization (e.g. "NAME likes an online course on FBAppName"). We basically achieved this. We lost some functionality which we deemed acceptable at this point in our evolution.
The short of it
I used the iframe version of the Facebook "like" button as dictated by the appropriate Facebook developer's page (for the link see semesm's answer for the link, I got no rep). I took their code snippet and manually removed the appId query string in the iframe's src.
In the "liked" page itself (which was the same page that had the "like" button) I used the Open Graph meta tags including specifying the appId. (These tags were specified: fb:app_id, og:type, og:url, og:site_name, og:title, og:description, og:image.)
The og:type was our custom type of the form 'namespace:app_custom_object_name'.
A failed approach
My first attempt was to use what I understand as the preferred method, the "HTML5" tab in the "Get Code" section of the developer's "like-button" page. I tried their method stripping the appId from the appropriate places. This method proved ineffectual.
If the domain doesn't match that in the Facebook App, there will be no "like" button.
If the domain does match, the "like" button will appear. However, it takes 3 clicks to actually "like" something. The first click changes the "thumbs-up Like" icon to a normal anchor with one word that didn't make obvious sense (I forgot what the word was). The second click will brings up the login/authorization window for using our app. The third actually bring up the modern fancy "like" box where you can type in a comment. I didn't find a way around this behavior.
Note that when I specified the appId in this approach on the appropriate domain, it worked as one would expect (though inconsistent with our desired behavior).
I did not try the other two options in the "Get Code" section of the "like-button" page.
Informed speculation and rumor
In my research around this, my overall impression is that requiring an appId is the way of the future for Facebook. Who knows if the old way will be depreciated, probably never, though I didn't find anything in the docs talking about this "legacy" behavior. This makes sense to me with their newer offerings and the advanced tracking that becomes available with this method.
I've seen suggestions that the "likes" used in this manner are akin to second-class citizens... treated as inferior in some respects. In my own experimentation I found the behavior of the fully specified appId (in the "like" button itself) to be different and more accessible and predictable (in terms of Open Graph queries and visibility on my limited Facebook tests) than the partially specified appId. (Again, I've found no solid documentation on this, and did not endeavor to full grok the differences.)
May this info help someone else along. Good luck!
So, I just tried the sємsєм method, as comments say: Facebook want you to login to get the code, and if you have an app, you have to choose one.
But if you don't, it gives you a code without any app reference.
So when you get a code – no matter any app you choose –, you just need to remove the appId parameter in the .js URL (&appId=##############), and you got (for the latest HTML5 code, 6th line):
js.src = "//connect.facebook.net/en_US/all.js#xfbml=1";
The code for the div element does not change.
I simply use the URL code inside an iframe tag without an appID and it seams to work,
here is an example:
<iframe src="http://www.facebook.com/plugins/like.php?href=<%=request.original_url%>&width&layout=button_count&action=like&show_faces=false&share=false&height=35&appId=" frameBorder="0" width="150" height="25">
</iframe>
According to Facebook's Social Plugins FAQ
Web: If you are using Social Plugins on the web, you do not need to create a Facebook app for integrating a Social Plugin.
iOS/Android: If you are using Social Plugins within a iOS or Android app, you need to create a Facebook app and tie it to your app identifier.
It seems that the official answer is that they are only required for iOS/Android.
There is a problem with Facebook applications/page tabs and Chrome/Internet Explorer users that have checked "secure browsing" setting in their profile but not only.
Problem rises when facebook opens our app by https protocol. Let's assume that we have app and all our resourcess accessbile by https. When user visits our app, everything working but not iframe/JS widgets, provided by external sites without SSL like some counters, instant messaging widget etc.
What to do if the page where widget comes from doesn't let us to generate ssl-version code, and also just changing http to https doesn't work because of lack of certificates/ssl enabled etc ?
TripAdvisor widget
The answer is : replace this script tag with TripAdvisor script
This :
<script src="http://www.jscache.com/wejs?wtype=sswidecollectreview&uniq=612&locationId=1480219&lang=en_US&border=true"></script>
To This tag from TripAdvisor Script
<script src="https://www.tripadvisor.com/WidgetEmbed-sswidecollectreview?uniq=831&locationId=308116&border=true&lang=en_US"></script>
and add [ S ] character to link for images [https] like this :
<a target="_blank" href="http://www.tripadvisor.com/"><img src="https://www.tripadvisor.com/img/cdsi/img2/branding/medium-logo-12097-2.png" alt="TripAdvisor"/></a>
To This :
<a target="_blank" href="http://www.tripadvisor.com/"><img src="https://www.tripadvisor.com/img/cdsi/img2/branding/medium-logo-12097-2.png" alt="TripAdvisor"/></a>
its work ...
Basically what the "padlock"/SSL indicator in the browser indicates is that the whole page is secure.
That means, no insecure content is included on the page without explicit warning by the browser that that is the case.
There may be browser specific workarounds (aka bugs), but relying on them for your page to work is not a good idea.
The best "workaround" is likely to just contact the people hosting the widgets and inform them about your problem, or if possible just plain hosting the widgets on your own secure site.
I'm going to add the ability to comments the products trought the "Facebook comments plugin" on a dynamic web marketplace based on Yii framework .
So, today I created a new facebook app, I included the facebook sdk js file and I added this html code to the view that render a single product:
<div class="fb-comments" data-href="<?=$this->createAbsoluteUrl('site/courseDetail',array('id'=>$model->course_profile_id))?>" data-num-posts="10" data-width="470"></div>.
The comment is linked to the URL!!
Well, what happens if the domain change or if I decide to add an url rewrite engine to my web application?
I suppose that I loose all the comments....weird....it is a big limitation...
I read the documentation: https://developers.facebook.com/docs/reference/plugins/comments/
and I saw that now is strongly recommended to use the html5 code because the FBML has been deprecated. Starting June 1, 2012 FBML apps will no longer work as all FBML endpoints will be removed.
So, I can't use the xid parameter such as on <fb:comments...>
right?
i am trying to put a like button on a page in a chrome extension that i've developed.
i use the simple XFBML version:
<fb:like href="http://www.mydomain.com/page?param=1&otherparam=2" send="false" layout="standard" width="400" show_faces="false" font="arial" ref="chrome_notification"></fb:like>
and of course i use the JavaScript SDK.
when i upload this page into my webserver, everything works just fine.
but when i run this page within my chrome extension, the like button itself works just fine, but the comment popup doesn't show.
in addition - i get these error masseges in the console:
Unsafe JavaScript attempt to access frame with URL chrome-extension://eindnjdghfmigkecgibjclhdnadlnbhm/../mypage.html from frame with URL https://www.facebook.com/plugins/like.php?api_key=&channel_url=http%3A%2F%2Fstatic.ak.fbcdn.net%2Fconnect%2Fxd_proxy.php%3Fversion%3D3%23cb%3Df3d383d278%26origin%3Dchrome-extension%253A%252F%252Feindnjdghfmigkecgibjclhdnadlnbhm%252Ff44dd2768%26relation%3Dparent.parent%26transport%3Dpostmessage&extended_social_context=false&font=arial&href=http%3A%2F%2Fwww.mydomain.com%2F%3Fparam%3D1%26otherparam%3D2&layout=button_count&locale=en_US&node_type=link&ref=chrome_notification&sdk=joey&send=false&show_faces=false&width=400. Domains, protocols and ports must match.
and -
Unsafe JavaScript attempt to access frame with URL https://www.facebook.com/plugins/like.php?api_key=158698534219579&channel_url=http%3A%2F%2Fstatic.ak.fbcdn.net%2Fconnect%2Fxd_proxy.php%3Fversion%3D3%23cb%3Df3d383d278%26origin%3Dchrome-extension%253A%252F%252Feindnjdghfmigkecgibjclhdnadlnbhm%252Ff44dd2768%26relation%3Dparent.parent%26transport%3Dpostmessage&extended_social_context=false&font=arial&href=http%3A%2F%2Fwww.mydomain.com%2F%3Fparam%3D1%26otherparam%3D2&layout=button_count&locale=en_US&node_type=link&ref=chrome_notification&sdk=joey&send=false&show_faces=false&width=400 from frame with URL http://www.facebook.com/plugins/comment_widget_shell.php?api_key=&locale=en_US&master_frame_name=f38cd100f8&sdk=joey. Domains, protocols and ports must match.
can anyone help me to find a solution for this?
Could it possibly by related to this known Facebook bug?
http://developers.facebook.com/bugs/293075054049400
Basically, one gets this behavior if secure browsing is enabled on the Facebook user's account.