#346 closed defect (bug) (fixed)
Activity Related RSS Feeds Broken
Reported by: | jvinch | Owned by: | burtadsit |
---|---|---|---|
Milestone: | Priority: | major | |
Severity: | Version: | ||
Component: | Keywords: | ||
Cc: |
Description
r840 - 2.7svn
Having lots of problems with rss feeds that relate to activity (sitewide and member)
- The feeds can be "seen" in Firefox ( http://img.skitch.com/20090113-8ki2p4w355n36ewgu21se4psrh.jpg )
- Adding them to readers (I tested with NetNewsWire and Google Reader) generates error. Adding feeds to Feedburner yields the same result.
- Feedvalidator gives 404 error for these feeds: ( http://img.skitch.com/20090113-1dcuaxyqf4u5stbcexuqypmxk7.jpg )
Change History (12)
#6
@
16 years ago
Andy I'm just looking at it today. I put on my day-glo orange hat. Broke out my best weapons (coffee and cigarettes). I'm hunting.
#7
@
16 years ago
I got the sitewide activity feed to stop throwing 404's which was trashing the feed validation. When the url mysite.org/activity/feed is encountered in wp this is what happens. wp fires up and before it does do_action('wp') and bp hooks the url wp populates the $wp_query
object. It decides that the url is a feed and also that it's 404. Telling wp that all is well with $wp_query->is_404 = false
makes things happy in the sitewide activity feed. Not in the member feeds. Don't know why.
`
function bp_activity_action_sitewide_feed() {
global $bp, $wp_query;
if ( $bpcurrent_component? != $bpactivity?slug? $bpcurrent_action? != 'feed' $bpcurrent_userid? ) return false;
$wp_query->is_404 = false;
include_once( 'bp-activity/feeds/bp-activity-sitewide-feed.php' );
die;
}
add_action( 'wp', 'bp_activity_action_sitewide_feed', 3 );
`
The changes above are the same idea that worked with eliminating the 404's in the member pages and directories.
bp is still throwing 404's in the member personal and friend feeds even though the same changes were made in bp_activity_action_personal_feed() and bp_activity_action_friends_feed() functions.
The feed validation still complains that we don't have any guid's in each feed item.
<guid isPermaLink="true">http://inessential.com/2002/09/01.php#a2</guid>
is what feedvalidator.org is looking for. These things *aren't* unique within the feed. As a test I stuck in a fake guid with $activity['link'] . (string)++$i
and made it happy. There isn't really a permalink to these items. I did <guid isPermaLink="false"> with the fake counter var and it was just as happy.
The guid just seems to be a suggestion for "interoperability with the widest range of feed readers". Detection of 'newness'.
#8
@
16 years ago
Perhaps it's just the site I'm testing this on. I can't figure out why the member feeds aren't just paying attention to my lying like the sitewide feed is.
#9
@
16 years ago
- Resolution set to fixed
- Status changed from accepted to closed
Burt, you were really close. As well as setting $wp_query->is_404 to false, we also need to set the status header so that the browser doesn't call this a 404 still.
Fixed in r1039
#10
@
16 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
Seems as though there is still a mixup between sitewide and member activity streams, reopening this for now.
At times the feed works and at times it doesn't. Not sure if it is related to the content in the feed at the time of trying to add it to google reader. It never works if there is forum posts in the activity feed. My main site works now, but other sites do not. Could it be just the content in the feed breaking this?