Skip to:
Content

BuddyPress.org

Opened 15 years ago

Closed 15 years ago

#1047 closed defect (bug) (fixed)

trunk bp_has_activities overrides a specified type due to backwards template compatability

Reported by: junsuijin's profile junsuijin Owned by: junsuijin's profile junsuijin
Milestone: 1.1 Priority: major
Severity: Version:
Component: Keywords: needs-patch
Cc:

Description

trunk's bp-activity/bp-activity-templatetags.php function bp_has_activities should not overwrite a passed type (ie the sitewide type from the site wide activity widget). This happens for example, on profile pages when you include a sidebar with the site wide activities widget.
Commenting out the following lines fixes the issue:

// The following lines are for backwards template compatibility.
	if ( 'my-friends' == $bp->current_action && $bp->activity->slug == $bp->current_component )
		$type = 'friends';
	
	if ( $bp->displayed_user->id && $bp->activity->slug == $bp->current_component && ( !$bp->current_action || 'just-me' == $bp->current_action ) )
		$type = 'personal';
	
	if ( $bp->displayed_user->id && $bp->profile->slug == $bp->current_component )
		$type = 'personal';

I think moving the legacy code above:

$r = wp_parse_args( $args, $defaults );
	extract( $r, EXTR_SKIP );

and just below the $defaults = array(
and then altering the $type accordingly (to reference the $args), would probably fix the problem while maintaining the backward compatibility, but I don't have a 1.0.3 installation to test against.

If a sidebar with the site wide activities widget shows on the same page as a user profile with personal or friend activity feeds, for example, the site wide activities widget will have duplicate content. The widget should always show site wide activities, as it would be otherwise useless on any pages with more specific activity feeds.

Change History (2)

#1 @junsuijin
15 years ago

just thought about this a bit more and we can probably leave the 'backwards template compatibility' code where it is, but set a var directly above it that checks for the existance of 'type' in $args, and then include that as part of the conditional for each proposed change of $type that happens in the 'backwards template compatibility' code. Perhaps something like the following untested code:

$o_type = wp_parse_args( $args );
$o_type = isset( $o_type['type'] );

// The following lines are for backwards template compatibility.
	if ( !$o_type && 'my-friends' == $bp->current_action && $bp->activity->slug == $bp->current_component )
		$type = 'friends';
	
	if ( !$o_type && $bp->displayed_user->id && $bp->activity->slug == $bp->current_component && ( !$bp->current_action || 'just-me' == $bp->current_action ) )
		$type = 'personal';
	
	if ( !$o_type && $bp->displayed_user->id && $bp->profile->slug == $bp->current_component )
		$type = 'personal';

#2 @apeatling
15 years ago

  • Resolution set to fixed
  • Status changed from new to closed

(In [1908]) Removing backwards compatibility code from activity loop since 1.0.3 templates had explicit parameters passed. Fixes #1047

Note: See TracTickets for help on using tickets.