La soumission de l'objet à Facebook via open graph ne fonctionne pas, mais alors après test de l'URL Facebook de l'objet du débogueur?
Je veux permettre à un utilisateur de mon application web pour être en mesure de publier plusieurs objets à leur chronologie d'une page (main_page).
J'ai déjà le jeton d'accès utilisateur stockées.
Tags sur la page que je suis en train d'essayer de soumettre, l'url est page_url:
<meta property="fb:app_id" content="my_app_id" />
<meta property="og:type" content="my_namespace:my_object" />
<meta property="og:title" content="some string" />
<meta property="og:description" content="some other string" />
<meta property="og:image" content="some_image_url" />
<meta property="og:locale" content="en_US" />
<meta property="og:url" content="page_url" />
Rails code de soumettre l'url, déclenchée à partir de main_page:
begin
fb_post = RestClient.post 'https://graph.facebook.com/me/my_namespace:do', :access_token=>user.get_facebook_auth_token, :my_object=>"page_url"
rescue StandardError => e
p 'e.response is'
p e.response
end
Sortie
2011-11-02T02:42:14+00:00 app[web.1]: "e.response is"
2011-11-02T02:42:14+00:00 app[web.1]: "{\"error\":{\"message\":\"(#3502) Object at URL page_url has og:type of 'website'. The property 'my_object' requires an object of og:type 'my_namespace:my_object'.\",\"type\":\"OAuthException\"}}"
La chose vraiment étrange, c'est que, après avoir fait cette erreur, si je test le page_url sur le Objet Du Débogueur, il passe sans erreurs/avertissements og:type
est le bon type et note 'website'
, puis exécutant les mêmes Rails code ci-dessus fonctionne correctement.
J'ai essayé sans le og:url
balise et la même chose arrive.
Mise à JOUR:
Comme par Igy de réponse, j'ai essayé séparant l'objet de grattage processus de l'action processus de création. Donc, avant que l'action a été soumis pour une nouvelle marque de l'objet, j'ai couru un mise à jour sur l'objet, avec scrape=true
.
begin
p 'doing fb_update'
fb_update = RestClient.post 'https://graph.facebook.com', :id=>page_url, :scrape => true
p 'fb_update is'
p fb_update
rescue StandardError => e
p 'e.response is'
p e.response
end
Sortie
2011-11-05T13:27:40+00:00 app[web.1]: "doing fb_update"
2011-11-05T13:27:50+00:00 app[web.1]: "fb_update is"
2011-11-05T13:27:50+00:00 app[web.1]: "{\"url\":\page_url,\"type\":\"website\",\"title\":\page_url,\"updated_time\":\"2011-11-05T13:27:50+0000\",\"id\":\id_here}"
La chose étrange est que le type est website
, et le titre est l'url de la page. Encore une fois, j'ai vérifié à la fois dans le code HTML et le Facebook du débogueur, et le type et le titre sont tous les deux corrects dans ces.
Vous devez vous connecter pour publier un commentaire.
Je suis en cours d'exécution dans la même question.
La seulement manière dont j'ai été en mesure de publier les actions pour les types d'objets personnalisés que j'ai défini est de tester manuellement l'objet d'url avec Objet Du Débogueur d'abord, et puis post de l'action sur cet objet par le biais de mon application.
Même à l'aide de la linter API -- qui Facebook suggère ici -- me donne une erreur.
Seulement de l'outil de débogage semble en fait gratter la page correctement.
Noter que je n'ai pas eu ce problème lors de l'utilisation d'un pré-défini type d'objet, comme le "site web":
Ce problème ne semble affecter les types d'objets personnalisés pour une raison quelconque.
MISE À JOUR (AVEC SOLUTION):
J'ai enfin compris cela. Le problème se pose à partir de mon application incapacité à gérer simultanément deux requêtes HTTP. (Pour info: je suis en utilisant Heroku pour déployer mon application Rails.) Lorsque vous faites une demande pour l'Facebook API de publier une action sur un objet URL (demande n ° 1), Facebook tentera immédiatement à gratter de l'objet de l'URL que vous avez spécifiée (demande n ° 2), et basé sur ce qu'il est capable de gratter avec succès, il renvoie une réponse à la demande initiale. Si je suis à court de demande n ° 1 de manière synchrone, qui va attacher mes processus web sur Heroku, rendant impossible pour mon application pour gérer la demande #2 en même temps. En d'autres termes, Facebook ne parvient pas à accéder à l'objet de l'URL qu'il a besoin de gratter; au lieu de cela, il retourne des valeurs par défaut, y compris le type d'objet "site web". Fait intéressant, cela se produit même lorsque j'ai tiré plusieurs processus web sur Heroku. L'application a l'intention d'utiliser les mêmes processus web pour gérer à la fois les demandes.
J'ai résolu le problème par la manipulation de tous Facebook API demandes de travaux en arrière-plan (à l'aide de delayed_job). Sur Heroku, cela nécessite de tir jusqu'à au moins l'un des processus web et un processus de travail. Si vous pouvez le faire, l'exécution de requêtes à l'API dans le fond, c'est une bonne idée de toute façon puisqu'il n'a pas la cravate de votre site web pour les utilisateurs, rendant d'attendre plusieurs secondes avant de pouvoir faire quoi que ce soit.
En passant, je recommande d'exécuter deux tâches en arrière-plan. Le premier devrait simplement gratter l'objet d'URL en Postant:
https://graph.facebook.com?id={object_url}&gratter=true
Une fois que le premier travail a été effectué avec succès, le feu jusqu'à une autre tâche en arrière-plan pour POSTER une action à la chronologie:
https://graph.facebook.com/me/{app_namespace}:{nom_de_action}?access_token={user_access_token}
MISE À JOUR PLUS RÉCENTE:
Par la suggestion dans les commentaires, à l'aide de la Licorne va aussi faire le tour sans la nécessité pour delayed_job. Voir plus ici si vous utilisez Heroku:
http://blog.railsonfire.com/2012/05/06/Unicorn-on-Heroku.html
L'Objet de la création de documents dire qu'elle doit gratter un objet, la première fois que vous créez une action contre elle, mais aussi dire
Sur cette base, je pense que vous devez ajouter
&scrape=true
à l'appel afin de vigueur immédiate gratter, puis essayez de créer l'action un peu plus tard. (Je crois que le message d'erreur que vous obtenez est probablement parce que la page n'a pas été mis en cache/gratté encore).De ce que j'ai vu, le Facebook Débogueur Page est le meilleur (et, à toutes fins pratiques, seulement) le chemin de la force de Facebook est de caches d'une page donnée de l'OpenGraph de l'information pour se rafraîchir. Sinon, vous allez passer jusqu'à une semaine attente de leur mise en cache des informations sur les pages qu'ils ont déjà gratté.
Fondamentalement, vous devriez
Il peut y avoir d'autres façons de forcer le Facebook des caches pour expirer; voir cette page Stackoverflow pour les solutions possibles. Je n'ai pas essayé encore, mais ils peuvent être utiles.