-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use actual social service APIs rather than SharedCount #57
Comments
Well, that's a big thorn in the side of the plugin. I was really happy with their service and love this plugin - let me know if I can help the transition in any way. |
Looks like we need to use FQL query to get all the various metrics for Facebook. |
Officially FQL is no longer available as of August 8, 2016: https://developers.facebook.com/docs/reference/fql/ I got it working with FQL, but I don't think we should release an update that uses this deprecated method that could stop working any day now. It appears the only way to do it moving forward it with the Graph API, which only returns a single count for "engagement" Even when I drop that in the Facebook Sharing Debugger I get "140160 likes, shares and comments (More Info)". The More Info link says likes and shares both show the same number - the combination of likes, shares and comments: So should we only include a single facebook option and a single facebook number? |
See the issue/57 branch for a working version. Key points:
|
Big problem. Facebook Access Tokens only last for one hour. You can go to the Access Token Debugger to see how long your token lasts. It appears there's a process for converting this to a long-lived access token, which lasts for 60 days (or forever, I can't tell). The user provides us with their user token (lasts an hour), and we make a request to Facebook using that, our App ID, and our App Secret. Facebook returns the "long lived" access token (lasts 60 days) which we store in the DB and use when making requests. When that one expires, the user has to go and get a new access token again. At this point I'm considering scrapping the Facebook API altogether and doing what we did for Google+ and simply scrape the count from the button. |
I created a Facebook App called "EA Share Count", then used its app id and secret key to try and generate a long-lived user token from my user token. $user_token = ea_share()->admin->settings_value( 'fb_access_token' );
$app_id = 'xxx';
$app_secret = 'xxx';
$url = 'https://graph.facebook.com/oauth/access_token?grant_type=fb_exchange_token&client_id=' . $app_id . '&client_secret=' . $app_secret . '&fb_exchange_token=' . $user_token;
$response = wp_remote_get( $url );
ea_pp( $response ); It didn't work. I got the following error:
I tried swapping out the app id and secret with those of another app I have (a client's that uses it for facebook comments), and that didn't work either. |
It appears people will need to create a Facebook App and get an App Token rather than a User Token. I've updated the settings page to include this link that walks through setting it up. Basic steps:
The only thing that worries me is the access token doesn't have the same info as any other access token I've seen. Here's the one I created for my website, billerickson.net: Here's a standard user token (expires in an hour) And here's a permanent token a client of mine is using (waiting to hear back how they created it): I think the difference is that the first screenshot is an App Access Token, while the second two are User Access Tokens. Regarding the code in this comment - Daniel Bachhuber pointed out I had
|
Here's a way to test SharedCount.com vs Facebook API results: https://gist.github.com/billerickson/e60b4d05f1da50b0e689bced628a6fc3 I placed it in my Core Functionality plugin for a local copy of my live site. It uses ea_is_dev_site(), ea_production_url() and ea_pp(), so make sure you have those in your CF plugin. Example Results:
I can now check this every now and then to see if SharedCount.com still works, and if the Facebook Access Token I generated above is still valid. |
I've added an admin notice, and the more information links here: No longer using SharedCount.com Let me know if you think any of the text should be changed. |
@billerickson just a heads up that engagedcount.com was started to fill the void of sharedcount shutting down - it handles the auth to the various services so your users would no longer need to configure anything again. |
SharedCount.com is shutting down (see email below).
It appears the issue is specific to SharedCount - they are using an old version of the Facebook API, and the newer ones no longer support bulk URL requests. Since we're only requesting single URLs, we can use the latest version of the Facebook API without any issues.
The downside is that instead of a single API call to SharedCount.com, we're not going to have an API call to each service.
I think we should update the backend UI so that for each service they can select whether or not to receive share counts. For many sites, the Facebook counts are all that matter - Google+ and Pinterest might always list 0 for their content.
The text was updated successfully, but these errors were encountered: