Opened 10 years ago
Closed 10 years ago
#5657 closed enhancement (fixed)
Ability to add profile fields programmatically, without touching DB
Reported by: | slaFFik | Owned by: | |
---|---|---|---|
Milestone: | 2.1 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Extended Profile | Keywords: | good-first-bug has-patch |
Cc: | tw2113@… |
Description
I'm talking about BP_XProfile_Group::get
So far it doesn't have filters before and after reseting indexes.
In BuddyPress 2.0.1:
wp-content/plugins/buddypress/bp-xprofile/bp-xprofile-classes.php:298
wp-content/plugins/buddypress/bp-xprofile/bp-xprofile-classes.php:301
Would be nice to have :)
Attachments (4)
Change History (13)
#2
@
10 years ago
Several scenarios:
1) ability to add fields in admin area on the fly (without saving them to DB)
2) ability to add fields on registration page on the fly with custom processing of their name=""
attributes on reg.form submission.
3) ability to filter out fields from displaying on front-end on either Profile tab, or Profile -> Edit.
Hope that helps.
#3
@
10 years ago
- Keywords needs-patch good-first-bug added
- Milestone changed from Awaiting Review to 2.1
Thanks, that does help.
I think that a procedural wrapper is still the way to go here. It's more the "WordPress way", and is in keeping with functions like bp_activity_get()
and groups_get_groups()
. Something like xprofile_get_groups()
, which would wrap the static class method and run the return value through apply_filters()
. Then find the two or three places where we call this method internally, and use the procedural wrapper instead.
This is an easy patch for someone who wants some props for 2.1 ;)
#4
@
10 years ago
- Cc tw2113@… added
- Keywords has-patch added; needs-patch removed
At least a first round for this. I don't know if there's much more to improve on offhand, but let me know if you see anything glaring.
#5
@
10 years ago
Thanks for the patch, tw2113! The inclusion of the phpDoc for the new method made me extra happy. :)
@boone Can you take a quick look at this and let me know if it's what you had in mind? It looks OK to me (not tested yet).
For consistency's sake, I would prefer to create a procedural wrapper for
BP_XProfile_Group::get()
, and then to put the filter there instead. Before doing that, can you say just a little bit more about how you're planning on using this? I would like to be sure that the filters are properly structured for your kind of use case.