#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)
Change History (10)
#2
@
10 years ago
- Summary changed from Get displayed user ID early in Extended Profile to Use displayed user ID in Extended Profile field groups
#3
@
10 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. :)
#5
follow-up:
↓ 9
@
10 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
@
10 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
@
10 years ago
- Owner set to boonebgorges
- Resolution set to fixed
- Status changed from new to closed
In 8823:
#8
@
10 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 :)
#9
in reply to:
↑ 5
@
10 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.
PS. Are Git-based patches acceptable? Scribu thinks they might be ;)