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 | Owned by: | 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.
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: