staze

Fixed my errors in netflix-x2 with this diff (of netflix-x2.php:

58,59c58,59
< 		$rss = fetch_rss($url);
< 		foreach ($rss->items as $item) {
---
> 		$rss = fetch_feed($url);
> 		foreach ($rss->get_items() as $item) {
65c65
< 			$raw_title = $item['title'];
---
> 			$raw_title = $item->get_title();
68,69c68,69
< 			$link = $item['link'];
< 			$description = $item['description'];
---
> 			$link = $item->get_link();
> 			$description = $item->get_description();
129c129
< 	$rss = fetch_rss($url);
---
> 	$rss = fetch_feed($url);

< means remove, > means add. Numbers are line number.

Not sure what would cause your fatal error.

Moved site to a 64-bit PHP install and TT now works. Again, could be coincidence, but… would be interesting to see if moving it back to 32-bit would break it again…

Alex,

I’m sorry if that came across as “this is definitely your fault”. I mean more than, it seems odd that I upgrade to PHP 5.3, it breaks 2.1.1 (and remained broken during all use of 5.3, which was for like a week). I downgrade to PHP 5.2.9 and it immediately starts working. I upgrade to TT 2.2.1, and it immediately breaks again with the same error as before, when the fixes in 2.2.x, from what I can tell, were related to the tw_id being treated as a string rather than number, and a 32bit PHP is going to have difficulty with numbers that large rather than strings.

Could be circumstantial… I fully understand that as a Sys Admin, but your site admits that you haven’t tested these changes on 32bit PHP. =/

Though I’ll certainly admit, the error seems to indicate an inability to connect to twitter, rather than an integer being too big for the PHP arch. But, it’s an odd coincidence. =/

My install stopped working too. Previously PHP 5.3.0 broke TT 2.1.1, so I moved back to PHP 5.2.9. Now TT 2.2.1 is broken in PHP 5.2.9. I get the same errors as before: fsockopen(): unable to connect to twitter.com:80 (php_network_getaddresses: getaddrinfo failed: System error)

Reading AK’s website, the only thing I can think is this is due to a 64 vs. 32 bit issue since he hasn’t tested these changes on a 32bit install of PHP (which I’m running). But who knows.

Been having issues with Twitter tools since upgrading to PHP 5.3. I get the following error:

[Mon Jan 11 20:42:13 2010] [error] [client 10.0.2.1] PHP Warning:  fsockopen(): php_network_getaddresses: getaddrinfo failed: System error in /Library/WebServer/Documents/website/wp-includes/class-snoopy.php on line 1142
[Mon Jan 11 20:42:13 2010] [error] [client 10.0.2.1] PHP Warning:  fsockopen(): unable to connect to twitter.com:80 (php_network_getaddresses: getaddrinfo failed: System error) in /Library/WebServer/Documents/website/wp-includes/class-snoopy.php on line 1142

Anyone else using WP 2.9.1, PHP 5.3, and Twitter Tools 2.1.2? =/

Thanks!

mintykt,

Out of curiosity, are you still seeing this, and if so, what version of PHP are you running?

Figured out (with the help of google), that if you have access to your mysql database that wordpress resides on, you can do this:

delete from wp_ak_twitter using wp_ak_twitter,wp_ak_twitter as vtable where vtable.id > wp_ak_twitter.id and vtable.tw_id = wp_ak_twitter.tw_id;

That will delete all the duplicate records from the table. You’ll want to do an optimize table after the fact.

This took my twitter tools table from 85693 rows (10.5MB) to 470 rows (59kb).

Obviously twitter tools needs to implement a check before inserting rows that makes sure the twitter id doesn’t already exist… but for now, this works.

Please make sure to do a mysqldump before attempting this. I don’t want to be liable for you losing your data.

Good luck!

I was having the same issue, but it turned out that it’s because twitter tools keeps a DB table of all tweets you’ve had. Problem is, there seems to be a bug that’s causing it to grab the same tweets more than once. My table grew to over 80k rows (I’ve tweeted less than 1000).

Duplicated the table, then emptied out the original, and things are back to normal. It still seems to be downloading them multiple times… so until that’s fixed (either a bug in the twitter api, or twitter tools), I’m just going to empty the table every couple weeks.

Might check it out. Table is called <wordpress-prefix>_ak_twitter (so, with a default install, it would be wp_ak_twitter.

That, combined with the SQL query to grab the tweets from the DB, made it really quite slow with 80k rows.

Just thought I would chime back in and say, I finally found something in the google webmaster tools forums saying this is a “google” problem.

https://www.google.com/support/forum/p/Webmasters/thread?tid=31379a96e11b23c5&hl=en

https://www.google.com/support/forum/p/Webmasters/thread?tid=52fa55f0c09b11e8&hl=en

Basically, google is trying to crawl some javascript code. It seems engineering has fixed the issue, as people (including myself) are starting to see 404 counts go down.

So, you should be able to just wait it out.

Thanks!

I’m seeing this same thing. For every page/link on my site, for some reason google is trying to look for: https://example.com/page/undefined and getting a 404. =/

Any luck finding the cause netslacker? I can’t figure out where it’s getting this link from… it’s not in the source for the pages.