Title: Preventing Application request limit errors Last modified: April 2, 2018 --- # Preventing Application request limit errors * Resolved [hommealone](https://wordpress.org/support/users/hommealone/) * (@hommealone) * [8 years, 2 months ago](https://wordpress.org/support/topic/preventing-application-request-limit-errors/) * Our app ID and app secret key settings have gone missing from our plugin’s options page. This has “broken” our website, as so many other forum threads have noted in the past. (No app ID and app secret key, and the plugin breaks the site eventually.) I don’t understand why those settings, which have been filled in and working for us for years, would have now come up empty. That is a problem in itself, but I would like to offer a suggestion. * Is it possible for the plugin to check first if the request limit has been reached, and only output the feed content if it has not? That seems like standard programming best practice: * Check for possible problem condition; If the problem condition is not encountered, then output the content; otherwise, output a notice instead. * Any chance something like that could be incorporated into the plugin’s functions? * If that’s not possible, maybe you could offer an option in the plugin settings: * If no app ID or secret key are entered, use our generic ones temporarily? [ ] yes [ ] no _(Note: using the plugin without an app ID and secret key may cause problems.)_ * If the site owner checks [x] no, the plugin outputs a notice instead of the soon- to-break or broken feed output. Notice could say: Please check the Facebook feed options. * In other words, give the owner the option to (opt in) to use your group app ID and app key, OR choose _not _to use it if there are no app ID and secret key entered. * Selecting “no” (should be the default setting) would prevent the website from breaking if the ap ID goes missing or becomes unusable for any reason. Viewing 13 replies - 1 through 13 (of 13 total) * Plugin Contributor [WD Support](https://wordpress.org/support/users/wdsupport/) * (@wdsupport) * [8 years, 2 months ago](https://wordpress.org/support/topic/preventing-application-request-limit-errors/#post-10148747) * Hi, * Thanks for the suggestions. We will consider them for the further updates of the plugins. * Regarding the issue with the app ID and app secret key settings, please note that we have not had a similar bug in the plugin. Could you please specify when/ after which action the information has been lost? We will check and provide feedback. * Thanks. Have a nice day. * Thread Starter [hommealone](https://wordpress.org/support/users/hommealone/) * (@hommealone) * [8 years, 2 months ago](https://wordpress.org/support/topic/preventing-application-request-limit-errors/#post-10150612) * Hi [@wdsupport](https://wordpress.org/support/users/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! * Plugin Contributor [WD Support](https://wordpress.org/support/users/wdsupport/) * (@wdsupport) * [8 years, 2 months ago](https://wordpress.org/support/topic/preventing-application-request-limit-errors/#post-10154033) * Hi, * Please note that the loss of information can be related to the migration, it depends on the steps that you have used while migrating. * Please see below answers to your questions: * **What exactly triggers the “Application request limit reached” notice, anyway?**_ Please note in the case you do not provide the App ID and the Secret Key in the Settings, we by default use our API. And in the case, it happens that many people do not provide their App ID/Secret Key the maximum request limit may be reached for a specific day. And as a result of this (in the case you do not use the Facebook Feed WD with your own Facebook App) te error appears. * **Is it possible that the loss (if there was one) was on the Facebook side?**– In the case you had the app and have set the APP ID, Secret Key, the Facebook App can be deleted only in the case if you have deactivated the account. * _Based on the following part of your post “especially since there is the small possibility that I never had my own app key, to begin with.”_ I can guess that App ID/Secret Key was not set. Is this the case? * Thanks. Have a wonderful day. - This reply was modified 8 years, 2 months ago by [WD Support](https://wordpress.org/support/users/wdsupport/). - This reply was modified 8 years, 2 months ago by [WD Support](https://wordpress.org/support/users/wdsupport/). - This reply was modified 8 years, 2 months ago by [WD Support](https://wordpress.org/support/users/wdsupport/). * Thread Starter [hommealone](https://wordpress.org/support/users/hommealone/) * (@hommealone) * [8 years, 2 months ago](https://wordpress.org/support/topic/preventing-application-request-limit-errors/#post-10155488) * 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? * Plugin Contributor [WD Support](https://wordpress.org/support/users/wdsupport/) * (@wdsupport) * [8 years, 2 months ago](https://wordpress.org/support/topic/preventing-application-request-limit-errors/#post-10164267) * Hey, * Please note that this will not be possible. Because we are requesting from the API and providing the information that is allowed by the API. * Besides that, the suggested way may bring to the slowness of the plugin. * Thanks. Have a nice day. * Thread Starter [hommealone](https://wordpress.org/support/users/hommealone/) * (@hommealone) * [8 years, 2 months ago](https://wordpress.org/support/topic/preventing-application-request-limit-errors/#post-10167237) * 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 '

Facebook feed temporarily unavailable.

'; } else { echo $fb_feed; }; } else { /* if plugin is de-activated */ echo '

Facebook feed temporarily unavailable.

'; }; ``` * 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? * Thread Starter [hommealone](https://wordpress.org/support/users/hommealone/) * (@hommealone) * [8 years, 1 month ago](https://wordpress.org/support/topic/preventing-application-request-limit-errors/#post-10247888) * We have now experienced the same problem even though we have a valid FB app ID and secret key in place. I don’t know what is causing the problem now! I’ve had to disable the plugin again. * Can you help me to investigate? * Surely, there must be some way that we can at least “limit the damage” so that when the feed is not properly/fully pulled from facebook, the partial code (missing closing tags, and perhaps throwing js errors(?)) doesn’t break the entire page? * If there is no way to limit the damage from the feed misbehaving, I will have to find another less desirable plugin… help please! * Thread Starter [hommealone](https://wordpress.org/support/users/hommealone/) * (@hommealone) * [8 years, 1 month ago](https://wordpress.org/support/topic/preventing-application-request-limit-errors/#post-10266856) * 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. * Plugin Contributor [WD Support](https://wordpress.org/support/users/wdsupport/) * (@wdsupport) * [8 years, 1 month ago](https://wordpress.org/support/topic/preventing-application-request-limit-errors/#post-10270418) * Hey, * Thank you for posting your suggestions. Our development team will discuss them and consider while working on further updates of Facebook Feed WD. * Regarding the “Application limit reached” error, there is a problem in the plugin. One of the HTML tags is not being printed, and this causes issues. * Our development team will fix this soon and update the plugin. Cheers! * Thread Starter [hommealone](https://wordpress.org/support/users/hommealone/) * (@hommealone) * [8 years ago](https://wordpress.org/support/topic/preventing-application-request-limit-errors/#post-10375184) * 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! * Plugin Contributor [WD Support](https://wordpress.org/support/users/wdsupport/) * (@wdsupport) * [8 years ago](https://wordpress.org/support/topic/preventing-application-request-limit-errors/#post-10378623) * Hi, * Previously script execution stopped when the API returned errors. This was a bug, and we fixed it. * The plugin has several built-in access tokens. It uses them to get data from FB. When any of this tokens has exceeded request limit, the plugin takes another one and uses it. The problem may arise only if ALL the tokens have exceeded rate limit, which is quite a rare condition. If it happens, the feed will output the error message on frontend (something like “API request limit exceeded …” ), but it will still display cached feed data. This feed data may be somewhat outdated, but it is preserved in WP DB until updated. So the feed should not be empty on the page. * Thanks. Have a nice day. * Thread Starter [hommealone](https://wordpress.org/support/users/hommealone/) * (@hommealone) * [8 years ago](https://wordpress.org/support/topic/preventing-application-request-limit-errors/#post-10379729) * 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? * Plugin Contributor [WD Support](https://wordpress.org/support/users/wdsupport/) * (@wdsupport) * [7 years, 12 months ago](https://wordpress.org/support/topic/preventing-application-request-limit-errors/#post-10390627) * Hi, * Please note that in the case your app key exceeds its request limit, the plugin tries to use one of ours. * Thanks. Have a wonderful day. Viewing 13 replies - 1 through 13 (of 13 total) The topic ‘Preventing Application request limit errors’ is closed to new replies. * ![](https://s.w.org/plugins/geopattern-icon/wd-facebook-feed_e0e3e1.svg) * [10Web Social Post Feed](https://wordpress.org/plugins/wd-facebook-feed/) * [Frequently Asked Questions](https://wordpress.org/plugins/wd-facebook-feed/#faq) * [Support Threads](https://wordpress.org/support/plugin/wd-facebook-feed/) * [Active Topics](https://wordpress.org/support/plugin/wd-facebook-feed/active/) * [Unresolved Topics](https://wordpress.org/support/plugin/wd-facebook-feed/unresolved/) * [Reviews](https://wordpress.org/support/plugin/wd-facebook-feed/reviews/) * 13 replies * 2 participants * Last reply from: [WD Support](https://wordpress.org/support/users/wdsupport/) * Last activity: [7 years, 12 months ago](https://wordpress.org/support/topic/preventing-application-request-limit-errors/#post-10390627) * Status: resolved