Preventing Application request limit errors

Hi @wdsupport ,

Thanks for considering those suggestions. If either is possible, it might save some users a bit of trouble.

Regarding your generous offer to help figure out what happened to our settings, I think it may not be worth a lot of time. If we had those settings in place – I think we did, but I can’t swear to it – they may have been lost when we recently migrated the website to another server, which would be an unusual and unlikely situation not worth bothering with.

Is it possible that we could have been using the plugin successfully for several years without having an individual app ID and secret key (instead relying on your shared app ID), and for some reason only had a problem now? What exactly triggers the “Application request limit reached” notice, anyway? Once your shared key reaches its limit, do all websites not using their own private key break at once?

Is it possible that the loss (if there was one) was on the Facebook side? When I went back into our Facebook Developers dashboard, I couldn’t find anything for your plugin listed among my “apps”. I vaguely remember setting one up, but again I can’t swear to it. It also seems like Facebook has gotten stricter in their policies for developer apps; they now require a URL of a privacy page, for example, before the app can be made “live”. Perhaps the “app” was somehow removed on the Facebook end because it didn’t meet these stricter standards? (I had to create a Privacy Policy page in order to be able to activate a new “app” to use with your plugin.)

Again, this is probably not worth a lot of time, especially since there is the small possibility that I never had my own app key to begin with. I’d much rather see you put any of your effort into implementing my suggestions at some point in the future. With those in place, websites would not break if a shared key reached its limit.

Thanks again!

Thanks again. Yes, if there is no other way to lose the Facebook App, then I must have never had one, since we had a Facebook Developers account alredy and none of the apps there were for your plugin. Apparently we never had an app ID, and it was only after a year or more that your shared app ID caused a problem. Probably for a batch of other people besides me too.

Thanks again for your answers and great plugin.

Instead of requesting the feed content from facebook and outputting it directly, perhaps the plugin could take the html that comes from facebook after the request is made, make it the value of a variable, check the variable for the string of text with the error message, and only output the variable value if the error text is not present?

I’m trying this in a template file; what do you think?

include_once( ABSPATH . 'wp-admin/includes/plugin.php' );
if ( is_plugin_active( 'wd-facebook-feed/facebook-feed-wd.php' ) ) {
  $fb_feed = do_shortcode('[WD_FB id="1"]');
  if (strpos($fb_feed, 'Application request limit reached') !== false) {
    echo '<p style="padding-top:1em;text-align:center;">Facebook feed temporarily unavailable.</p>';
  } else {
    echo $fb_feed;
  };
} else { /* if plugin is de-activated */
  echo '<p style="padding-top:1em;text-align:center;">Facebook feed temporarily unavailable.</p>';
};

Putting the generated feed into the $fb_feed variable and then echoing it is working. But I don’t know if my code for checking the $fb_feed string for “Application request limit reached” will catch those times when the application request limit is actually reached. (With a private app ID and secret key, mine has not exceeded the limit.)

What do you think? Can you test this somehow?

The recent problem was, according to the plugin authors, due to a change to the Facebook API lowering the number of allowed requests in a given time period. They now recommend that the “Feed autoupdate interval” field setting should have a minimum of one hour (although the instruction below the field still shows “Minimum 1 min.”). The lugin settings page should reflect this new change to the API.

Regarding my suggestions about preventing broken pages when the request limit is reached, I’ve since learned that the Facebook API returns an error code when the allowed request limit is exceeded. I have privately suggested to Web Dorado that they check for this returned notice and don’t output the feed if the notice has been returned. I believe that a competing plugin is doing that. That competitor also returns a hidden (display:none) message to developers in the front-end webpage, in place of the bad feed, telling the API error code, and linking to a troubleshooting page which details what to do if you receive various error codes.

Hi,

Before I noticed that there was an update available for this plugin, our site crashed again due to this same problem. I updated the plugin to Version 1.0.35, and the problem disappeared. Thanks!

In the changelog, you note:

1.0.35

• Fixed: Crash on front end when API returns error
• Improved: Use another access token if API request limit of current token is exceeded

Any chance that you could share a little more detail about those improvements?

Have you incorporated any kind of indicator that let’s the site owner know when a request limit has been exceeded? (Perhaps outputting a paragraph with an error notice, and display:none?)

Have you incorporated a public message? (Perhaps outputting a paragraph that reads “Facebook feed temporarily unavailable.” in place of the feed, if the request limit is exceeded?

Thanks again for your attention to this issue!

Thanks for that additional information; much appreciated.

You wrote:

When any of this tokens has exceeded request limit, the plugin takes another one and uses it.

The last couple of times that the plugin broke our website, we were using our own private FB app key. In the event that our own app key exceeds its request limit, does the plugin now try to use one of yours, as a fallback?