This user has reached the maximum allowable queries against Twitter's API for the hour. about tweet-display-back

[mbabker]

Do you have caching enabled? If so, how long is the cache life? You are
only allowed 150 queries per hour on your account on the API that data is
being retrieved from. There are checks in place to ensure that data is
actually being returned to flag that message to display, so it shouldn't
be a 'false positive'.

On 7/2/11 10:41 PM, "patience"
[email protected]
wrote:

I keep getting this when i refresh the page. It works on localhost but
when i am on live site, i keep getting that and it goes away fro 5
minutes and i get it again

using the latest developer release.

Reply to this email directly or view it on GitHub:
#12

Have you enabled the cache? And used a decent value? (like 20 minutes x 60 = 1200 seconds)

[patience-zz]

I enabled the system cache plugin and still had the problems. Now I enabled the cahce from the configuration with 15 min.

should i leave them both on or no?

[mbabker]

At a minimum you should leave the module's cache enabled. The system
cache plugin or the global configuration cache won't make a difference
here.

On 7/4/11 10:52 PM, "patience"
[email protected]
wrote:

I enabled the system cache plugin and still had the problems. Now I
enabled the cahce from the configuration with 15 min.

should i leave them both on or no?

Reply to this email directly or view it on GitHub:
#12 (comment)
77

[patience-zz]

I have done that too.. it still times out. not sure what it might be then?

[mbabker]

I've actually seen it happen on my own site a couple times and as soon as
I clear the cache, then the info loads. I don't know how to nail down why
that message happens inconsistently because I've pulled that JSON source
simultaneously from 3 sources before and gotten different results.

On 7/12/11 3:18 AM, "patience"
[email protected]
wrote:

I have done that too.. it still times out. not sure what it might be
then?

Reply to this email directly or view it on GitHub:
#12 (comment)
80

[patience-zz]

I even cleared the cache from the backend and it is still the same.

Really like the component and hate to lose it :(

Did you wait a hour?
How did yoiu entered the 15 minutes? 15?
Try a value of 1200 (the module uses seconds I think) for example. Remember if you get that warning, you have to wait a hour.

[patience-zz]

The module tooltip says enter it in minutes so i had it as minutes. I just changed it to 1200

I'm not 100% sure, but I think the code uses seconds. Can you give it a
look Michael?
Meanwhile, try this new value :)

Please let us know if it works

[patience-zz]

yeah, I will see what happens with the new value. If i doesn't work, I am ready to give my pass to Micheal to look at my settings if he wants.

[mbabker]

I might not have changed the tooltips (if so, I'll correct them). For Joomla! 1.5 and 1.6, the cache needs to be in seconds. I think I saw a commit for Joomla! 1.7 that sets it to be in minutes. Try using seconds first (15 minutes is 900 seconds) and let's see what happens.

[patience-zz]

I did that too and still has the same problem :(.

did you wanna login to my site and look at it in the backend?

That's a pitty... How much tweets are you showing? I think it's a good idea to give Michael your login details (don't post it here online!).

[mbabker]

Message sent with directions.

[patience-zz]

Email sent.

[jf123]

Any update on this issue??

I have the same problem on Joomla 1.6.3. I have Joomla cache set to 30 minutes and module cache set to global 1800.
Even when I delete the cache, I get the same problem. And also when I try different Twitter accounts.

[mbabker]

I've done everything I can to prevent the error from occurring in my code. There are numerous other variables that I cannot handle, such as server side caching or what information is actually being retrieved from Twitter. I've looked at the JSON that the hit count is checked against, queried simultaneously from 3 different sources, and it has returned different outputs each time. I'm not sure what else I can do to prevent it from occurring, if anything.

[bjamminb]

i am having this issue too.. anyone found a fix?

[bjamminb]

sorry, should mention i'm on joomla 1.5.23 in legacy mode with TDB 2.0

[mbabker]

It's been occurring for me a lot more lately, but I think it has something
to do with Twitter's API. As I've said previously, I've done everything I
can in my code to prevent the error from occurring, but completely
removing this check is ill advised because other errors will occur if the
rate limit is not checked.

On 8/11/11 2:57 PM, "bjamminb"
[email protected]
wrote:

i am having this issue too.. anyone found a fix?

Reply to this email directly or view it on GitHub:
#12 (comment)
40

[giovannicandido]

Hello.
I think this problem can be softened if the module use the oauth api that have an limit of 350 request per oauth access. Like say in twitter documentation "Unauthenticated calls are permitted 150 requests per hour. Unauthenticated calls are measured against the public facing IP of the server or device making the request." this means that the same server can't make more then 150 requests per hour even the module are instaled in two diferents joomla instalations.

See in https://dev.twitter.com/docs/rate-limiting

I'm glad if I can participate in this project, I can make this feature and share code back, if someone is not already working on it

[mbabker]

Heh, I didn't realize the rate limiting was done against a specific IP, so
thank you for that.

I haven't really taken a deep look into Oauth authentication yet, it
honestly has felt like a bit more than necessary for a module that only
pulls data. Obviously, if Twitter required Oauth and took away
unauthenticated pulls, I'd implement it without a doubt. I guess the
biggest issue would be implementing a simple to use method of adding the
Oauth data to the module for authentication. If you want to work on code
for it, I would greatly appreciate it.

On 8/31/11 7:04 PM, "giovannicandido"
[email protected]
wrote:

Hello.
I think this problem can be softened if the module use the oauth api that
have an limit of 350 request per oauth access. Like say in twitter
documentation "Unauthenticated calls are permitted 150 requests per hour.
Unauthenticated calls are measured against the public facing IP of the
server or device making the request." this means that the same server
can't make more then 150 requests per hour even the module are instaled
in two diferents joomla instalations.

See in https://dev.twitter.com/docs/rate-limiting

I'm glad to participate in this project, I can make this feature and
share code back, if someone is not already working on it

Reply to this email directly or view it on GitHub:
#12 (comment)
03

Just a thought, if the caching of the TDB module is set to yes, does the user also have to enable the cache at the global settings? If so, maybe setting this to no is causing the error for some users.

Rok Twittie is using Oauth I think, but the module failed big time with my website.

[mbabker]

The way I wrote the caching setup in the module dispatcher, it should be completely independent of the global cache. If a cache file isn't getting created in the site cache folder with global to no and module to yes, then there is an issue that needs to be addressed.

[patience-zz]

using the latest version and Still have this problem. I just checked your website and it seems like you got the same problem as well. haha

[mbabker]

I'll add an option to bypass the check. I'm not getting any support from Twitter's folks on their dev forums in trying to help chase this down either, and I'm not skilled enough to write my own caching mechanisms for the JSON data, so the bypass option is the best I can offer without completely removing the check.

[patience-zz]

How long for that update?

I just got this recently. "Due to an error, potentially a timed-out connection to Twitter, this user's tweets are unable to be displayed."

First time getting it, maybe twitter is over loaded with Steve jobs posts. :(

[mbabker]

Later in the processing I check to ensure that the user profile and tweet stream actually return data, and if not, the message you posted is displayed. It could mean the API is timing out due to high use (like the RIP Steve tweets), the connection errored out, or a proper data object was not returned.

I'll post a developer release in the next few days with the change.

[mbabker]

A new developer release is posted which contains the added bypass option.

http://www.flbab.com/extensions/latest

[patience-zz]

Warning: Attempt to assign property of non-object in /home/content/22/7892122/html/modules/mod_tweetdisplayback/helper.php on line 42
Due to an error, potentially a timed-out connection to Twitter, this user's tweets are unable to be displayed.

latest version.

[Thetjo]

Just spent some time trying to figure out a solution to this issue. The thing is that you've got the best Twitter handler for Joomla, but this issue was preventing me from using it :)

Most likely the cause for many people is that they are using shared web hosting. The Twitter API looks at the public facing IP for unauthenticated requests. This IP is shared amongst many users of a shared hosting package (some of my tests showed multiple thousands). If just one of these websites doesn't have a proper limit on their requests to the Twitter API, this one site will burn through the 150 allowed requests, effectively blocking the other domains from reaching the API (no matter how good the caching is on those websites).

With the way you've currently set up your caching, the message will show even though there might be a valid cache available (that I'd must rather show than an error message). Below you'll find a rewritten portion of mod_tweetdisplayback.php file, that now uses a custom caching mechanism. This one only creates a new cache file once it was able to reach the Twitter API. I have tested this and it seems to work very well. The only known caveat is when a server is so crowded that the code is unable to reach the API at all, but that was a problem with the original code as well.

// Check if caching is enabled
if ($params->get('cache') == 1)
{
    // Fetch cache time from module parameters (in seconds)
    $cacheTime = $params->get('cache_time');

    // Set file to save cached tweets in
    $cacheFile = JPATH_CACHE . '/tweets.json';

    // Set initial value for variable
    $twitter = null;

    // Cache file more than set amount of seconds old?
    if(!file_exists($cacheFile) || time() - @filemtime($cacheFile) > $cacheTime)
    {
        // Do a request to the Twitter API for new data
        $twitter = ModTweetDisplayBackHelper::compileData($params);

        // No errors occurred, limit not yet reached?
        if (!isset($twitter->error) && (!isset($twitter->hits) || is_null($twitter->hits)))
        {
            // Save new data to cache file
            file_put_contents($cacheFile, json_encode($twitter));
        }
    }

    // Only load content when creation was successful
    if(file_exists($cacheFile))
    {
        // Fetch data from cached file
        $twitter = file_get_contents($cacheFile);
    }
}
else
{
    // Do a request to the Twitter API for new data
    $twitter = ModTweetDisplayBackHelper::compileData($params);
}

// Decode json back to regular object?
$twitter = (!is_object($twitter) && json_decode($twitter) != NULL) ? json_decode($twitter) : $twitter;

Regards,
Theo

PS: sorry for probably not using the proper GitHub button to contribute this and let me know if you have any questions.

[mbabker]

It looks good in theory, I'll definitely test it some later on. If you want to contribute it as a pull request, all you need to do is navigate to the file and click the edit button near the top of the page. GitHub takes care of the rest.

[mbabker]

@Thetjo you might be interested in looking at 4593cac as I've (finally) gotten around to implementing your code, just a bit differently based on some other structure changes.

[Thetjo]

Looks good! I'll check it out further another time. Let's hope this resolves most of the bug reports about this problem.

[j2studio]

Unfortunately I am still experiencing the warning. I have downloaded the 2.14 version today and installed on a new test site here: http://j2studio.com/unatampabay/ - any ideas?

I love this module because it is responsive!!! Hopefully this can be resolved.

[mbabker]

Try the 3.0 beta. The cache mechanism is greatly improved.

On Thursday, December 20, 2012, j2studio wrote:

Unfortunately I am still experiencing the warning. I have downloaded the
2.14 version today and installed on a new test site here:
http://j2studio.com/unatampabay/ - any ideas?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/12#issuecomment-11583648.

• Michael

Please pardon any errors, this message was sent from my iPhone.

[chinners]

Hi Guys - unfortunately I'm experiencing this issue on the latest v3 stable code. I've tried with or without cache but most of the time it comes up with the error. Enabling cache just appears to freeze the last successfully shown tweets. Also tried using user or list set-up with same results.

It's a great module otherwise and hope someone can come up with solving the issue of too many requests being made from a shared server environment.

[chinners]

Follow-up: I don't know whether this is coincidence or is actually a way of circumventing the limitation imposed by Twitter, but I have just created a Twitter widget and placed the code in the footer - the Tweet Display Back module now seems to be working!

[mbabker]

The updated cache system in 3.0 is intended to hold on to the last good pull of data from Twitter until it can get new data instead of caching an error message. So, what you saw there is intended behavior.

There aren't anymore rate limit checks in the code. Reading up a bit more on the new API rate limiting, what happens is that all users are under a rate limit imposed on my application token because of the authentication method used. This also depends on which endpoint is being hit. All of these limits are the number of requests per 15 minute window:

• User profile: 180 requests
• Favorites: 15 requests
• Lists: 180 requests
• User timeline: 300 requests

So, what is most likely happening is the application's rate limit is being hit (everyone uses the same API keys, and there've been over 4500 downloads of the 3.0.1 release). I started working code to catch the error messages being returned by the API, but it isn't being displayed anywhere yet. That's my next step. I'll also probably turn on caching in the code regardless of the user turning it on or off so that there's always cached data saved to be displayed.

[chinners]

Appreciate it Michael. Give my RAF regards to you and yr troops.

[jphansen]

Would it by any chance be possible to use "our own" Twitter api-token ?

We really love this module, but the dreaded "Due to an error, potentially a timed-out connection to Twitter, this user's tweets are unable to be displayed." that comes up 9 times out of 10, makes the module impossible to use.

[mbabker]

I'd have to devise a way to allow users to authenticate to the Twitter API themselves (that popup you get basically when you're using Twitter to log into websites, something like that). It's something I've thought of in the past, but haven't really explored not knowing how well I'd be able to implement it or how difficult it would be.