Skip to:

Opened 14 years ago

Closed 13 years ago

Last modified 13 years ago

#2447 closed defect (bug) (no action required)

activity: change strings to constants in a few places

Reported by: aesqe's profile aesqe Owned by:
Milestone: 1.5 Priority: normal
Severity: Version:
Component: Activity Keywords: has-patch dev-feedback
Cc: aesqe@…


I don't know if anyone is working on this, but here's a few things I've noticed so far:


function bp_activity_action_friends_feed
on line 504
change 'friends' to BP_FRIENDS_SLUG


lines 189 - 233 and lines 869 - 884

change strings to constants

I'll add to this list if I notice this problem anywhere else.

Attachments (2)

2447.001.diff (4.1 KB) - added by cnorris23 14 years ago.
patch for 1.2.x
2447.002.diff (4.1 KB) - added by cnorris23 14 years ago.
patch for trunk

Download all attachments as: .zip

Change History (16)

#1 @cnorris23
14 years ago

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

These are actually all correct. The $bp->current_action object reference remains unchanged, regardless of how the BP_FRIENDS_SLUG, or related constant, may be defined. For example, if you are viewing your friends, the $bp->current_action will be 'friends,' even if BP_FRIENDS_SLUG is defined as 'enemies.'

#2 @aesqe
14 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened


if you change BP_ACTIVITY_SLUG and go to someone's friends' activity stream, everything looks OK.

But if you change BP_FRIENDS_SLUG, you'll only see your own updates on your activity->friends stream.

Also, $bp->current_component and $bp->current_action do not remain unchanged, they very much take on the values of wp-config constants.

(checked with WP 3.0, BuddyPress, and no other plugins installed, default bp theme)

#3 @cnorris23
14 years ago

  • Keywords needs-patch added; constants defines strings removed


You are right in that there is an issue with activity streams when viewing profile pages, whether your own or that of another member. However, your proposed solution isn't correct. It works, but the reason it works is the actual issue. You are right that $bp->current_component changes, and that it takes on the value of the constants, but I never mentioned $bp->current_component, nor did I state anything to the contrary. When it comes to $bp->current_action, my original assertion stands. This is where the problem lies. On profile pages, $bp->current_action is taking on the value of a related constant, when it should really be one of the following (friends/groups/favorites/mentions). I haven't yet tracked down why this is happening since I've run out of time for now. I'll come back later and change some of the details of the ticket to better reflect the actual problem.

#4 @aesqe
14 years ago


I see, and you're absolutely right, I should have considered that possibility too :/

Thank you for looking into it, I'll leave a comment if I manage to find anything related.

#5 @cnorris23
14 years ago

  • Keywords has-patch dev-feedback added; needs-patch removed

First, it should be said that this effects both the 1.2.x branch, and trunk. I know I read somewhere that 1.3 is going to make it easier to customize URLs, so I don't know if this means we should just change this to a 1.2.5 milestone and wait and see what happens with 1.3, or if we should stick with the current milestone of 1.3.

Now, on to the issue. Turns out this was caused by an issue in bp_activity_setup_nav() where the constants, BP_FRIENDS_SLUG and BP_GROUPS_SLUG, were passed to the bp_core_new_subnav_item() slug parameter, when the expected values for bp_has_activities() to function properly are 'friends' and 'groups.' For those with javascript disabled, the issue also exists in the members/index.php template of bp-default. The following patches fix both issues for both 1.2.x and trunk.

14 years ago

patch for 1.2.x

14 years ago

patch for trunk

#6 @cnorris23
14 years ago

  • Milestone changed from 1.3 to 1.2.5

#7 @johnjamesjacoby
14 years ago

  • Milestone changed from 1.2.5 to 1.3

I'm going to bump this back to 1.3.

If we're going to allow slugs to change, they /should/ change here as well. I started writing a patch but noticed this was touching quite a few files for such a small use case, so it gets the punt.

Note: cnorris23's patches will alleviate the problem until 1.3 rolls out

#8 @paulhastings0
14 years ago

  • Summary changed from activity: change strings to constants in a few places to [patch] activity: change strings to constants in a few places

#9 @DJPaul
13 years ago

  • Summary changed from [patch] activity: change strings to constants in a few places to activity: change strings to constants in a few places

We will need to review this with the component page change in 1.3

#11 @cnorris23
13 years ago

  • Resolution set to invalid
  • Status changed from reopened to closed

Constants are deprecated in 1.3

#12 @aesqe
13 years ago

@cnorris23 can you tell me how are component slugs translations handled in 1.3?

thanks :)

#13 follow-up: @cnorris23
13 years ago

@aesqe Hope that didn't alarm you. Slug constants will still work, for now, but they are no longer the preferred way to change slugs. Each component's respective $bp global slug value has replaced constant instances throughout 1.3 code, which invalidates this ticket. For each component, which now utilize the BP_Component class (see source:trunk/bp-core/bp-core-component.php and source:trunk/bp-activity/bp-activity-loader.php), there are filters to alter the slugs. This will also make it easier for plugins/themes to modify slugs rather than depending on wp-config.php or bp-custom.php.

#14 in reply to: ↑ 13 @aesqe
13 years ago

thanks for the clarification, cnorris23 :)

Note: See TracTickets for help on using tickets.