[buddypress-trac] [BuddyPress] #5220: Overhaul implementation of xprofile field types

[buddypress-trac]

#5220: Overhaul implementation of xprofile field types
-------------------------+------------------------------
 Reporter:  DJPaul       |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  XProfile     |     Version:
 Severity:  normal       |  Resolution:
 Keywords:               |
-------------------------+------------------------------

Old description:

> It's pretty hard to add a new type of profile field to BuddyPress; some
> plugins such as [https://github.com/donmik/buddypress-xprofile-custom-
> fields-type/](this one) do a good job, but we make it hard because we
> hardcoded values and checks and templates across several places. Examples
> of new profile field types might be inspired by HTML5 input types such as
> number or email (#4694), or a birthday field (#4582), or advanced types
> like a map/co-ord mashup (#5028).
>
> Places that need changing (currently via actions or filters) when you add
> a new profile field type are listed below. There may be more, as I'm
> still re-discovering where everything is:
>
> * Templates in `/members/single/profile/edit.php`,
> `/members/register.php`, `BP_XProfile_Field->render_admin_form()`.
> * Logic in `bp_core_screen_signup()`, `xprofile_screen_edit_profile()`
> and `xprofile_set_field_data()`.
>
> I believe profile types should be implemented as a class; there's a lot
> of places where we can benefit from an object orientated approach to
> profile field types. And, eventually, I'd like it to be as easy to add a
> profile field type to BuddyPress as creating a Group extension is. No
> changes to other files, filters, or actions should be required.

New description:

 It's pretty hard to add a new type of profile field to BuddyPress; some
 plugins such as [https://github.com/donmik/buddypress-xprofile-custom-
 fields-type/ this one] do a good job, but we make it hard because we
 hardcoded values and checks and templates across several places. Examples
 of new profile field types might be inspired by HTML5 input types such as
 number or email (#4694), or a birthday field (#4582), or advanced types
 like a map/co-ord mashup (#5028).

 Places that need changing (currently via actions or filters) when you add
 a new profile field type are listed below. There may be more, as I'm still
 re-discovering where everything is:

 * Templates in `/members/single/profile/edit.php`,
 `/members/register.php`, `BP_XProfile_Field->render_admin_form()`.
 * Logic in `bp_core_screen_signup()`, `xprofile_screen_edit_profile()` and
 `xprofile_set_field_data()`.

 I believe profile types should be implemented as a class; there's a lot of
 places where we can benefit from an object orientated approach to profile
 field types. And, eventually, I'd like it to be as easy to add a profile
 field type to BuddyPress as creating a Group extension is. No changes to
 other files, filters, or actions should be required.

--

Comment (by DJPaul):

 Fixing link in description

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5220#comment:2>
BuddyPress <http://buddypress.org/>
BuddyPress