Do Facebook Like Buttons require an App ID? - facebook
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.
Related
Facebook comment plugin doesn't work at all
I inserted the facebook code where required and absolutely nothing happens or shows up. Using dreamweaver cs6 and in live view or when testing in ANY browser, nothing shows up. It's a blank box. ANy thoughts? I read somewhere that the website must be made into an application of facebook? Is this something?
Specifically, after activating the plugin and properly connecting the plugin to the facebook app,which does work and has been used extensively before hand, comments simply fail to load. There is no comment box, no past comments pull in either (note the app has historical comments already). In the plugin settings area on the right side of the screen where the comments check box exists, there is a read more link that takes you to the facebook developers page where it discusses adding the facebook comments iframe. If there is some other location where comment settings might also exist (past the three fields that require the 2 keys and the app name) I could not find them and this was not referenced in the plugin setup.
Why does Object debugger say my URL is a facebook URL and isn't "scrapable"
In trying to create an "object" page for my first facebook app, I've run into some difficulty. I followed Facebook's Open Graph Tutorial nearly exactly. After creating an "object" html page with the appropriate <meta property="og:... tags I tried running the URL through the Debugger Tool as suggested in the tutorial but I'm given the following error: "Facebook URLs aren't scrapable by this Debugger. Try your own." This page is in the same directory on my company's linux box as the canvas page, and is certainly not a "Facebook URL". If it matters, I'm using an IP instead of a domain name: xx.x.x.xxx/app/obj.html ... I continued the tutorial anyway, but ultimately it does not seem to want to post a new action/object (is this even right?). I did however manage to get something to work, as in the app timeline view I apparently actioned one of those objects a couple hours ago. I assume this happened when I was pasting curl POST commands into the terminal. I'm pretty new to the whole open graph, and facebook APIs, etc., so I'm probably operating under false assumptions of some sort, and I've been all over trying different things, but this error seems pretty bizarre to me and I can't seem to resolve it. UPDATE I just took the object page and put it on my own personal shared hosting acct. The debugger worked (inexplicably) fine on it, but I couldn't go too far since it's a different domain than the one authorized by my app.
Make sure og:url inside your html page does not point to facebook. Also, make sure to look at the open graph protocol page (to see you formatted the og tags correctly. Also, make sure the page is accessible to everyone, not just yourself.
Without knowing the URL it's hard to be sure, but it's most likely that your URL is either including a og:url tag pointing to a facebook.com address, or a HTTP 301/302 redirect to Facebook instead
Preserve Google +1, Facebook Like, and Twitter Tweet This button counts after URI change
My question is very simple: is there any way to (programmatically, technically, or manually) make a Google +1, Facebook Like, or Twitter Tweet This button preserve its count after a change of URI? Programmatically: Doing something with the javascript to make it show the combined counts of two URIs while posting the new action to only the latter. Technically: Do they detect and follow a 301 redirect from the original resource? Is there any special text I can include in the HTTP header to tell them that they should move all "points" from the old URI to the new one? Manually: Some form somewhere on their site that I can submit or someone I can email that will be able to copy our points over to the new URI? (note that I use URI and not URL in this question on purpose. The canonical resource link is changing from something.php?id=idnumber to /mycoolproduct/) EDIT Bounty started, but don't answer with "it can't be done"
I believe there is only one solution that fits your request above universally. That solution would be to 301/302 the old URIs to the new URIs and then keep using the old URIs with your social buttons. All the major social buttons allow you to specify the URL for which to like/g+/tweet/etc. This would preserve your existing social share counts and all shared posts would still direct to the same page. The choice now becomes whether to 301 or 302 redirect. A 302 may help preserve current search placement and avoid loosing your ranking if its pretty good. A 301 redirect (moved permanently) will cause search engines to start indexing your new URLs and dropping the old ones. This might cause a loss in current search rankings. It appears that as of this post, nobody is honoring redirects for social votes of any kind. So I think the the safest route is to 302 redirect and continue to use the old URIs for social votes. You will keep your equity this way, but must maintain your redirects and become even more invested in the old URI template. How are your redirects implemented? .htaccess? or in page? You will need to weigh the cost-benefits for your case. Otherwise you should probably 301 and start using the new URIs for your social buttons. In this case you might loose your social equity, but are free to build new without fear of messing up anything. If the social equity you are replacing can be recouped in say 6 months or less I wouldn't bother with it and start fresh. However, this brings up an interesting point. You mentioned programatically adding two counts. Well yes, you could put together some JavaScript to add a couple counts together, but I gotta ask why? Adding them together for visual display purposes will not actually help increase referral traffic or search ranking. So its just a facade that I don't think helps you. If you're just looking to fool your visitors into thinking you're popular, why not just generate an image server side that keeps counting up. (bad joke, don't do it!) Bottom line you can't actually redirect your social equity, you may be able to pretend to have moved it, but you can't actually. Considering your original question asks about several social buttons, its important to note that even if one or two of these services started honoring redirects when applying social votes, it wouldn't relieve you from making the decisions above. You'll still need the redirects for existing backlinks, and if you are supporting multiple social buttons on your page the choice of redirect type will need to be made with all of the social buttons in mind.
I can't speak for how to do this with Twitter/G+ but for Facebook: You can't 'move' the likes and comments between URLs, and for new content you should definitely start using the new URLs, but for your existing URLs you can still have the original like counts/comments work if you: Continue pointing the Like button on the new URL to the old URL (i.e <fb:like url="http://oldurl"/> Add an exception to your redirect code so that when Facebook's crawler (facebookexternalhit/1.* - currently 1.1) accesses it, the original set of open graph meta tags are displayed (this will keep the description, title, thumbnail, etc, working as before) Other users that land on the 'old' URL will still be redirected to the content in its new location
I have a real solution to this problem it might not be the most conventional but it does work 100%. Using a simple jQuery plugin called sharrre. Keep in mind I'm not the best jQuery coder (If you see improvements please let me know!) but this works regardless.
Here is how I did it on my site:
Using the sharrre plugin you can add the current share count to any element on your page. I simply got the data for both URLs then added them together and displayed them on the like, tweet, share, etc buttons.
This example is with Twitter but I'm doing this with Facebook, Google Plus, Pinterest and Linkedin. Here is the code:
<li id="twitter" data-url="CURRENT-URL" class="twitter sharrre"></li>
<li id="twitter-old" data-url="OLD-URL" class="twitter sharrre" style="display: none;"></li>
Then I called sharrre's code:
$(function(){ sharrreItUp(); }
This is how my function looks on my .js file:
function sharrreItUp() {
$('#twitter').sharrre({
share: {
twitter: true
},
enableHover: false,
click: function(api, options){
api.simulateClick();
api.openPopup('twitter');
}
});
$('#twitter-old').sharrre({
share: {
twitter: true
}
});
setTimeout(function(){
var oldTwts = $('#twitter-old .box .count').html();
var newTwts = $('#twitter .box .count').html();
$('#twitter .box .count').html(parseInt(oldTwts) + parseInt(newTwts));
}, 2000);
}
And BAM... you have your new URL being sharrred and the old shares from different social networks get added into them.
Unfortunately, there is no solution for this. We have tried all possible solutions and you will simply lose your social equity if you do a 301 Redirect. We found it to not be worth the hassle of trying to maintain our vote counts, and have instead pointed our buttons to the homepage in the interim of moving to the new url structure.
demo: http://so.devilmaycode.it/preserve-google-1-facebook-like-and-twitter-tweet-this-button-counts-after-ur/
i don't wanna say something wrong, but i think you just need to define the URI inside each share button, so no matter from what URL the vote come from, the defined url will be used as count.
if you, instead already have two different sources and you want to join it, you should follow the iframe src and scrape the count from it; for google +1 the div id that contain the count is #aggregateCount for twitter is #count; an example could be as below:
<?php
$doc = new DOMDocument();
$doc->loadHTMLFile('iframe-url-goes-here');
$count = $doc->getElementById('aggregateCount');
echo $count->nodeValue;
?>
then, on your page after the DOM is loaded and the widget are loaded, you can append your own value.
hope this help, in anycase i prefer the first way.
Put in the head of the new page <meta property="og:url" content="old_url_here"/> This way Facebook attributes likes for the old page. The only downside is that this way when people share your link, the old rich snippet will be included.
Tab links using only the page and app_id has stopped working, is there an alternative beyond querying Facebook each time?
A few days ago these type of links worked: http://www.facebook.com/pages/132456789?sk=app_132465798465 but now they give 404's. The alternative is link to the namespace of the page like so: http://www.facebook.com/pages/foo/1456798324564?sk=app_134654689794 however to find out the link I'd need to ask Facebook for it, and it seem like since the namespace can change I can't just ask for it once. Is there another way to use page and app id's to link to tabs without needing the roundtrip to Facebook?
I don't think that first format was ever used on Facebook, i'm surprised it worked. As far as I can tell the 'name' part of a page URL is arbitrary, so just filling in something there will work, e.g. http://www.facebook.com/pages/Tea/194040780316?sk=info will also work as http://www.facebook.com/pages/some_random_text/194040780316?sk=info
How To stream.publish Within a Profile Tab
I have successfully setup an iFrame based App using the Javascript SDK, and we are trying to enable it on a Page Tab. It seems Facebook has changed some things lately, because the app breaks when added to the Page Tab. I even went as far as making sure that all external scripts were included in the main index.php file, and that the body tags were taken out. No, I'm trying to find out if it is even possible to use methods such as the stream.publish within a Profile Tab at all. It seems like it isn't. As far as I can tell, you can no longer use any social methods on the Profile Tab. Here were two related articles on the subject: insidefacebook.com/2010/08/19/facebook-moving-toward-iframes-over-fbml-for-canvas-apps-and-page-tabs/ -and- developers.facebook.com/roadmap If anyone can confirm or deny this, it would be a huge help. The Facebook docs are just all over the place. Here's a link to the working App Canvas as it stands now: http://apps.facebook.com/votetesting/
I know that on tab pages, you cannot do any JS until the user clicks on something first. Maybe that is the problem. -Roozbeh