Asked  7 Months ago    Answers:  5   Viewed   32 times

We have been opening a sharing popup (via with the URL like[title]=EXAMPLE&p[summary]=EXAMPLE&p[url]=EXAMPLE&p[images][0]=EXAMPLE 

and until some unknown point in the last month or so everything was fine.

What is happening now is; the popup dialog appears and correctly includes the Title, Description, Image and URL provided by the query string parameters, but when the post is submitted, the resulting wall post on Facebook is missing the Title, Description and Image, though it still links to the correct URL.

Does anyone know if there have been recent changes which could have suddenly stopped this from working?

Pre-empting some common responses:

  • "sharer.php URL was deprecated" - usage seemed to continue and it seemed the consensus was that it was largely considered to be sticking around - I haven't seen any specific indication that it should have suddenly ceased working - might have missed something

  • "Use JavaScript SDK/these OG meta tags" - not possible in my specific situation - just trust me ... I can explain if you REALLY want but it's really not relevant.

  • "Use the feed dialog" - not suitable due to lack of support for posting with attachments on FB pages



Facebook no longer supports custom parameters in sharer.php

The sharer will no longer accept custom parameters and facebook will pull the information that is being displayed in the preview the same way that it would appear on facebook as a post from the url OG meta tags.

Use dialog/feeds instead of sharer.php

Official answer from fb team

Wednesday, March 31, 2021
answered 7 Months ago

When the popup login box loads and the user signs in/connects, the box then loads the site with ?code=XXX appended to the url. So for the site I added a php if statement

    if (isset($_REQUEST['state']) && isset($_REQUEST['code'])) {
        echo "<script>
} else {
        // load page

What this does is close the popup and reload the original page that initiated the popup.

Saturday, May 29, 2021
answered 5 Months ago

I found a workaround - profile pictures of various sizes can still be accessed via an FQL query:

$pic = $facebook->api(array('method'=>'fql.query', 'query'=>"SELECT pic_big FROM user WHERE uid=$fb_uid"));

("pic_big" is equivalent to "type=large" - see here).

This still doesn't explain why the GRAPH call suddenly broke though, or why image sizes don't seem to be accessible via Graph at all anymore (which I'd still like to know)...but at least there's some way to get the other size photos.

Gotta love Facebook and their top-notch reliability...

Thursday, August 5, 2021
Preet Sangha
answered 3 Months ago

Ladies and Gentlemen, I resolved it all - I just needed to use $access_token = $session->getToken();. This helped me negate the call for code exchange which was causing OAuthException because Facebook has since changed their policy on the exchange code from being used more than once.

Now "App Secret Proof for Server API calls" is properly enabled under the App advanced settings tab as recommended by Facebook.

So the specific solution in complete:

$app_id = 'APPID'; $app_secret = 'APPSECRET';
FacebookSession::setDefaultApplication($app_id, $app_secret);
$redirect_url = "";
$helper = new FacebookRedirectLoginHelper($redirect_url);

try {
    $session = $helper->getSessionFromRedirect();
} catch (FacebookRequestException $ex) {
} catch (Exception $ex) {

if (isset($session)) {
    $access_token = $session->getToken();
    $appsecret_proof = hash_hmac('sha256', $access_token, $app_secret);
    $request = new FacebookRequest($session, 'GET', '/me', array("appsecret_proof" =>  $appsecret_proof));
    $response = $request->execute();
    $graphObject = $response->getGraphObject();

   echo print_r($graphObject, 1);
} else {
    echo '<a href="' . $helper->getLoginUrl() . '">Login</a>';
Wednesday, August 11, 2021
answered 3 Months ago

The new version of ti.facebook iOS was released just today and can be downloaded here:

The error was not related to the arch's, but to the UIApplicationOpenURLOptionsAnnotationKey constant that was only iOS 9 and so not working with Xcode < 7. That is now fixed as well. Thanks!

Friday, August 20, 2021
answered 2 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :