About a month ago YouTube decided to get rid of it's "tags" from the frontend of their website:
http://youtubecreator.blogspot.com/2012/08/tags-removed-from-video-watch-pages.html
Which also in turn left media:keywords blank through any API feed request as read here:
http://apiblog.youtube.com/2012/08/video-tags-just-for-uploaders.html
The nice thing was for another month or so (until a few days ago) you could still access a video's "tags" or "keywords" through the API by looping through the category term(s)
It seems YouTube has taken that away also and it now only displays ONE category term for each API feed...and most of the time they are the basic YouTube categories like "Music" or "People" etc.
My questions to the YouTube development team is why was this taken away from the API (I understand taking it away from the frontend of the website) and will it ever return in any form to the API?
In the original Creators blog post you guys stated:
"Tags remain an important way to organize and help others find your videos. We strongly encourage you to continue tagging videos -- this will help increase your audience by improving the discoverability of your content."
So if Tags are still important and still utilized for search results...why in the world are they not available through the API anymore?
Any help and/or info would be greatly appreciated as this has completely destroyed the functionality of MANY of my sites! Thank you.
It appears they've made them private and you must use an authorized API request with adequate channel privileges to access them now. This really sucks since I've used them for filtering videos from a channel on a site and making authorized connections to the API via PHP has been complicated for me to get working correctly.
And the fact that this added complication is ONLY for keywords seems a bit ridiculous, but I don't guess the Youtube API team cares.
Unless a WHOLE lot of people complain about it, I doubt they'll add this back as a public.
I just added
Update: This change also applies to <category
scheme="http://gdata.youtube.com/schemas/2007/keywords.cat"> tags,
which were not mentioned in the original announcement.
to the announcement blog post. <category> tags should have been removed for the same reason <media:keywords> was removed, but due to an oversight they were left in unauthenticated API responses for a few weeks. There are no plans to add back keyword information via either metadata field.
If your goal is to have some semantics in the video, Freebase Topics can help. You can for instance do a JSONp call
<script src="https://www.googleapis.com/freebase/v1/topic${item}?filter=/type/object/name&callback=putFBname"></script>
with a small javascript function
<script>
function putFBname(respuesta){
span=document.getElementById(respuesta["id"]);
span.innerHTML=" "+respuesta["property"]["/type/object/name"]["values"][0]["text"];
}
</script>
to get the name of the topic.
Freebase topics come in the API v3.
Related
I have my site working using the Facebook Comments Plugin as you can see here http://www.amanzitravel.com/namibia-wildlife-sanctuary
I am trying to use the Graph API to retrieve the comments so they are on the page in a form that is beneficial for SEO (as outlined here https://developers.facebook.com/docs/plugins/comments/).
Ideally I want to see not only all comments, but replies to comments. According to the API (https://developers.facebook.com/docs/graph-api/reference/v2.0/object/comments) using filter=stream should do the trick.
However when I do that I only get the two most recent comments e.g. https://graph.facebook.com/comments/?ids=http://www.amanzitravel.com/namibia-wildlife-sanctuary&filter=stream as opposed to the default https://graph.facebook.com/comments/?ids=http://www.amanzitravel.com/namibia-wildlife-sanctuary where I get all the top level comments but none of the replies.
EDIT: Further to this, it appears to update itself some time later, but when another reply is added it goes back to displaying a subset of all the comments for a period of time. Its unfortunate because it means I can't rely on this to be accurate.
Is there anyway I can make this work properly?
There are some old posts related to this topic but the API has since changed, so I wanted to ask again. Is there any way to remove photo tags with the Facebook API?
I saw this documentation about deleting photo tags with the graph API.
https://developers.facebook.com/docs/reference/api/photo/#tags
You can delete a tag for a particular user in the photo by issuing a HTTP DELETE request to /PHOTO_ID/tags/USER_ID or PHOTO_ID/tags?to=USER_ID.
Deleting a tag on a photo requires the publish_stream permission and supports the following parameters.
Parameter Description Type Required
to USER_ID of the User to tag; can also be string yes
provided in URL path (see above).
If the deletion is successful, you get the following return.
Description Type
If the deletion succeeded boolean
It did not work when I tried it. Instead, I always get the following error:
{
"error": {
"message": "(#3) Application does not have the capability to make this API call.",
"type": "OAuthException",
"code": 3
}
}
I submitted a bug report to Facebook and they seemed to acknowledge a bug by putting it into "triaged" status. Then a few weeks later, although several other developers had subscribed to the bug report, they closed the case with this explanation:
We are prioritizing bugs based on impact to the developer community. As this bug report has not received much attention from other developers, we are closing it so as to better focus on the top issues. There is a good chance your issue is due to an implementation problem in which case you can try to find help on Stack Overflow.
The bug report is here: https://developers.facebook.com/bugs/122135101317762
Can anyone help me figure out how to untag via the API? My app is currently written as a Web app, not as a mobile one.
Thank you in advance for any help on this.
Update: As Christopher Blizzard explains in the accepted answer, this isn't in fact a bug, but intentional behaviour that was previously badly documented.
Before this was known, back when this answer was first posted, I investigated a little to try and figure out if there was any way around this restriction. The answer is no. I've left the detail of my findings below in case they are of interest to anybody in the future, but Christopher Blizzard's input makes most of this obsolete.
I'm reasonably confident that the answer is no, there's no way at all. I've exhausted all possible lines of investigation I can think of, and come up blank. Let me list my findings:
1) The bug affects both ways of deleting photo tags listed in the documentation.
Sending a delete request to https://graph.facebook.com/PHOTO_ID/tags/USER_ID/ and sending one to https://graph.facebook.com/PHOTO_ID/tags?to=USER_ID should both work, according to the documentation. However, in reality, both approaches fail with the following error, as you've already observed:
{
"error": {
"message": "(#3) Application does not have the capability to make this API call.",
"type": "OAuthException",
"code": 3
}
}
2) It's got nothing to do with your app's permissions
Using Graph Explorer you can easily test this stuff out using an access token that grants you all possible permissions, and deleting tags still fails.
3) It's got nothing to do with the user's privacy settings
I tried creating a new user on Facebook and setting every single privacy setting in the settings menu to the most lenient option available. It made no difference.
4) It's not to do with the photo's owner or how the original tag was created
Even when the person whose access token you're using owns the photo that the tag is on and created the tag themselves, you still get the same error when trying to delete the tag. This applies whether they created the photo and tag through the normal Facebook user interface, or with your app through the Graph API.
5) There's no workaround using APIs other than Graph
FQL only allows data retrieval, not insertion, modification or deletion. Open Graph has no methods relating to photos or photo tags. The deprecated REST API - which is still functional, but which Facebook instructs us not to use, and whose documentation has been taken down - has functioning methods for getting and adding tags, but none for deleting them, as you can see in a a cached version of the documentation, via the Wayback Machine.
6) There doesn't seem to be any way to delete a tag using POST requests.
You can change the location of an existing tag, but that's it. Specifying an invalid location throws an error and doesn't affect the existing tag. Specifying the to field twice in a post request to try and change the target of a tag throws an error and has no effect.
7) Others have tried to solve the same problem before, and they have not succeeded.
I haven't found many posts about this issue, but there are these two, neither of which are helpful:
Delete photo tag from Graph API
http://queforum.com/facebook-applications/78655-facebook-untag-user-photo-via-facebook-graph-api.html
After testing all the points above, I'm out of ideas. Of course, there's no way I can say with certainty that this is impossible - we don't know what's going on on Facebook's back end or why the bug exists. I think these tests represent a pretty thorough examination of the problem, though, and they haven't revealed any solution.
I just updated the documentation on developers.facebook.com, but the short version is that the delete tag API is whitelisted only for certain apps.
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.
I am quite new to facebook API. I have used the open graph to generate actions and objects.This actions are now validated by facebook.
But, I have a translation trouble : the action and object are necessarily in english. And the facebook doc say that the action and objects are automatically translated when the meta tags are made 'locale', which was done. But my site is french and the actions an objects are still appearing in english. Does anyone can hep ?
(The ref's doc:https://developers.facebook.com/docs/opengraph/internationalization/, http://developers.facebook.com/blog/post/605/ )
Best ,
Newben
If you’re already refering to the documentation – why don’t you read it as well?
The blog post says how translating your app works, and https://developers.facebook.com/docs/internationalization/ describes it in more detail.
I'm trying to integrate the Facebook comments left on our site in a way in which the content can be crawled by search engines and also for people (although I highly doubt there will be many) who don't have Javascript enabled on their browser.
Currently our Facebook comments are displayed via the use of the Facebook comment social plugin (using the <fb:comments href="MY_URL" num_posts="50" width="665"></fb:comments> tag). This ends up rendering an iFrame (which are mostly ignored by search engine crawlers) so the plan is to render this information and format it with basic HTML. To do this, the comments are pulled using the Graph API - this is then only be displayed to crawlers and people with Javascript disabled.
This all works nicely using the Graph API call (https://graph.facebook.com/comments/?ids=MY_URL), parsing the JSON result and displaying it on the page. The problem is that the <fb:comments> approach filters our results based on a blacklist we have set up on one of our Facebook Apps. The AppId with the relevant blacklist is stored on the page using metadata (<meta property="fb:app_id" content="APP_ID"/>) which the <fb:comments> control obviously must somehow use to filter the comments.
The problem is the Graph API method does not filter any results as I guess no blacklist (or App Id containing a blacklist) is specified. Does anyone know how to specify a Facebook App ID to the API call URL or of another way to not fetch commnents back that violate the terms of the blacklist?
On a side note, I know the debate about filtering content in comments rages on but it is a management decision to implement the blacklist, and one that I have no influence in changing - just incase anyone felt the need to explain the reasons why content filtering is or isn't a good idea!
Any thoughts on a solution?
Unfortunately there's no way to access a filtered list of comments using the API - it might be a reasonably request to have this in the API - you should file a wishlist item in Facebook's bug tracker
Otherwise, the only solution I can think of is to implement your own filter on your side when retrieving and displaying the comments from the API.
According to the Comments plugin documentation the filter on Facebook's side is implemented as a simple substring match, so it should be trivial to implement.
A fairly simple regular expression match should be able to check each comment against a relatively long list quickly.
(Unfortunately, the tradeoff here is that implementing a filter is easy, but you'd also need to write an interface so that whoever's updating the list of disallowed words can maintain the list for both the Facebook plugin, and your own filtering.)
Quote from docs:
The comment is checked via substring matching. This means if you blacklist the
word 'at', if the comment contains the sequence 'a' 't' anywhere it will be
marked with limited visibility; e.g. if the comment contained the words 'bat',
'hat', 'attend', etc it would be caught.
Pretty sure there is no current way of doing this from the graph API, the only thing I can suggest is taking the blacklist and build your own filter