I realised that once I'd posted, and I'm on lite mode just now, so couldn't be bothered faffing around to edit.

I'll have a look at my own Wordpress site tonight to see what the code's like.

The syntax for LIMIT on the end of the query is incorrect. It should contain a second number after the comma, i.e. LIMIT 0, 10.

One of the WordPress PHP scripts is probably supposed to check for a variable in the URL query which tells the script how many entries form your blog it is supposed to output into the RSS feed. If this script isn't checking the variable correctly and an empty string (or worse any data) is being allowed to be used to form part of the LIMIT clause then that could cause the error you've described.

To fix it you could try and upgrade WordPress to see if it is a known bug that has been squashed in a newer version. Failing that it's probably best to tell them about it ASAP in case the bug can be used to perform an SQL injection attack.

Thanks. I'll give updating a try...

But why then does the feed work for everyone else except this one aggregator? I have a feed for the blog set up with LiveJournal, and it still works (as in new posts show up), two other blog aggregators still show my new posts as i make them, and if someone subscribes to my blog's feed, it works there too (at least, it does for me - and yes, i subscribe to my own blog's feed).

And as i said, this was working fine up until i moved the blog database to the new hosting a few weeks ago. So i'm not certain it's a WP issue and maybe something that went screwy with the database import? Altho wouldn't that bugger it up for all feeds from my blog?

I don't know.

If I had to guess, I would say the feed aggregator that has the problem could quite possibly be trying to limit the number of entries it is sent and because of this [possible] bug in WordPress the RSS feed isn't correctly generated and it falls over.

Meanwhile the aggregators that do work are not limiting the number of entries they fetch which means the bug doesn't come into play for them.

Or it could be the other way around and WordPress is expecting a URL Query variable to tell it how many entries to fetch and the troublesome aggregator isn't providing it.

Well, i'll start by upgrading to 2.0.5 and see what that solves, if anything.

Thanks again!

 
function get_posts($args) {
	global $wpdb;
	parse_str($args, $r);
	if ( !isset($r['numberposts']) )
		$r['numberposts'] = 5;
	if ( !isset($r['offset']) )
		$r['offset'] = 0;
	if ( !isset($r['category']) )
		$r['category'] = '';
	if ( !isset($r['orderby']) )
		$r['orderby'] = 'post_date';
	if ( !isset($r['order']) )
		$r['order'] = 'DESC';
 
	$now = current_time('mysql');
 
	$posts = $wpdb->get_results(
		"SELECT DISTINCT * FROM $wpdb->posts " .
		( empty( $r['category'] ) ? "" : ", $wpdb->post2cat " ) .
		" WHERE post_date <= '$now' AND (post_status = 'publish') ".
		( empty( $r['category'] ) ? "" : "AND $wpdb->posts.ID = $wpdb->post2cat.post_id AND $wpdb->post2cat.category_id = " . $r['category']. " " ) .
		" GROUP BY $wpdb->posts.ID ORDER BY " . $r['orderby'] . " " . $r['order'] . " LIMIT " . $r['offset'] . ',' . $r['numberposts'] );
 
	update_post_caches($posts);
 
	return $posts;
}
 

Sorry about that; my mind was kind of mush last night. It's in functions.php, as you've found.

I'm not a PHP expert, but I'm wondering if there's some condition where the variable is set to null, or an empty string or something, so it passes the isset() test, but doesn't show up in the string.

What say the PHP experts?

Without seeing how the function arguments are handled it's hard to say for sure.

But, if that is the only test they're performing on the data then they need to add more. At the moment a variable could be an empty string and it would pass their basic checks.