Skip to:
Content

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#5809 closed enhancement (fixed)

Use displayed user ID in Extended Profile field groups

Reported by: Offereins Owned by: boonebgorges
Milestone: 2.1 Priority: normal
Severity: normal Version: 2.0
Component: Extended Profile Keywords: has-patch
Cc:

Description

Setting the stage:
In Dashboard > User > Extended Profile, the admin page is built with metaboxes in BP_Members_Admin::user_admin_load() using the bp_members_admin_user_metaboxes action hook. The XProfile component makes use of this by adding meta boxes for each of the profile fieldgroups in BP_XProfile_User_Admin::register_metaboxes(). The fieldgroups are collected through bp_has_profile() which uses the new (BP 2.1) bp_xprofile_get_groups().

The issue:
While the edited user ID is provided in the metaboxes hook, bp_has_profile here does not use that ID to setup the $profile_template global, but instead uses bp_displayed_user_id() in bp_xprofile_get_groups. The thing is, that this function returns 0 (empty) on this point, because the displayed user ID is not set. Yet, in BP_Members_Admin::get_user_id() the edited user ID is found in the uri query args with $_GET. Later on in the admin page, bp_displayed_user_id() does return the right user ID.

The solution:
By sending the edited user ID from the action hook to bp_has_profile(), the function will not default to bp_displayed_user_id(). Yet, bp_displayed_user_id() still fails around here.

Attachments (1)

5809.1.diff (1.9 KB) - added by Offereins 4 years ago.

Download all attachments as: .zip

Change History (10)

@Offereins
4 years ago

#1 @Offereins
4 years ago

PS. Are Git-based patches acceptable? Scribu thinks they might be ;)

#2 @Offereins
4 years ago

  • Summary changed from Get displayed user ID early in Extended Profile to Use displayed user ID in Extended Profile field groups

#3 @DJPaul
4 years ago

Git or SVN-based patches are fine. Historically, most of the BP core devs used SVN, but I think most of use Git now, so we're used to -- and am very happy -- dealing with both kinds. After all, a contribution is a contribution; we're not going to be picky about the patch file format. :)

#4 @DJPaul
4 years ago

  • Milestone changed from Awaiting Review to 2.1

#5 follow-up: @boonebgorges
4 years ago

Good catch, Offereins. Thanks!

Git patches are fine, but there's something odd in your patch that is causing it not to apply. (I'm getting a message "patch unexpectedly ends in middle of line" and I can't massage the patch to make it work.) Sounds to me like it's related to line endings. Would you mind having a look at this article https://help.github.com/articles/dealing-with-line-endings#platform-all and making sure you've configured git to use autocrlf properly for your OS? Thanks for your patience and contributions!

#6 @boonebgorges
4 years ago

Just a brief side note: passing the proper 'user_id' here doesn't actually make any functional difference as far as I can see. When 'fetch_fields=false', the user_id param is not looked at at all.

That said, it's still useful for plugins etc to have the proper user_id.

#7 @boonebgorges
4 years ago

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

In 8823:

Pass the proper user_id when setting up xprofile meta boxes on the Community Profile Dashboard panel

The default value, bp_displayed_user_id(), is not defined at this point, so we
must manually pass the $user_id.

Fixes #5809

Props Offereins

#8 @Offereins
4 years ago

@boonebgorges:

Just a brief side note: passing the proper 'user_id' here doesn't actually make any functional difference as far as I can see. When 'fetch_fields=false', the user_id param is not looked at at all.
That said, it's still useful for plugins etc to have the proper user_id.

Indeed, that actually is the reason how I stumbled upon this issue: developing my plugin, the filter in bp_xprofile_get_groups() had a $args['user_id'] value of 0 where I was wanting to know the right user ID. So even though the user ID is not used in the function right there, it has or may have a meaning further on in the chain of logic.

Thanks for the implementation and I'm glad my efforts are helpful :)

Last edited 4 years ago by Offereins (previous) (diff)

#9 in reply to: ↑ 5 @netweb
4 years ago

Replying to boonebgorges:

Git patches are fine, but there's something odd in your patch that is causing it not to apply. (I'm getting a message "patch unexpectedly ends in middle of line" and I can't massage the patch to make it work.) Sounds to me like it's related to line endings. Would you mind having a look at this article https://help.github.com/articles/dealing-with-line-endings#platform-all and making sure you've configured git to use autocrlf properly for your OS? Thanks for your patience and contributions!

Also adding the .editorconfig Sublime Text plugin will help in this regard.

Note: See TracTickets for help on using tickets.