[buddypress-trac] [BuddyPress Trac] #5799: Bring profile fields back into template parts

[buddypress-trac]

#5799: Bring profile fields back into template parts
-----------------------------+------------------------------
 Reporter:  johnjamesjacoby  |       Owner:
     Type:  enhancement      |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  XProfile         |     Version:  2.0
 Severity:  normal           |  Resolution:
 Keywords:  2nd-opinion      |
-----------------------------+------------------------------
Changes (by boonebgorges):

 * cc: espellcaste@… (removed)


Comment:

 Can you be more specific about how you're looking to change the output
 experience?

 The only thing that is output by the class which might potentially be
 modifiable by the theme is what is defined in `edit_field_html()` - that
 is, the markup displayed when a user is editing his profile. If that's
 what you mean, then it is possible to override it, by overriding the
 class:

 {{{
 function bp5799_override_datebox( $fields ) {
     $fields['datebox'] = 'BP5799_XProfile_Field_Type_Datebox';
     return $fields;
 }
 add_filter( 'bp_xprofile_get_field_types', 'bp5799_override_datebox' );

 class BP5799_XProfile_Field_Type_Datebox extends
 BP_XProfile_Field_Type_Datebox {
     public function edit_field_html( $raw_properties = array() ) {
         // Generate your own HTML
     }
 }
 }}}

 Obviously, this is not a very "themey" way of doing things, but it does
 show that it's possible.

 Two ways we could make this content easier to modify:
 - At the beginning of each `edit_field_html()`, look for a template part
 in the theme, and load it and bail if found.
 - Put the markup generated in `edit_field_html()` into an output buffer
 and pass it through `apply_filters()` before spitting it out.

 However, I would argue that it's not a great idea to do either of these
 things. While it should be (and is) possible to override our default
 markup, we should not encourage it. The syntax of form markup is very
 particular, both in terms of HTML standards and in terms of what will make
 our save logic work. We do not want it to be overly easy for themers (a
 class of people that includes lots of beginners) to mess this up.

 What's being produced in `edit_field_html()` is, for the most part, just a
 `<label>` element and the corresponding `input`/`select`/`textarea`. In
 the vast majority of cases, any necessary customization to these fields
 can happen through JS or CSS. If there are some areas where the markup
 that BP creates for these form elements is insufficient or incomplete, we
 should fix it in core, or add more limited filters (eg, it might make it
 easier to use a library like Chosen if we had filters on some of the CSS
 selectors). Overriding the markup totally should be a last resort, and our
 current API sorta makes it a last resort.

 One last brief thought: while technically, what you've described here is a
 "regression" from the old way of doing things (in the sense that you did,
 in fact, used to be able to override this markup in a template), I would
 say that it's not a regression in spirit. One of the biggest problems of
 our previous implementation was that it put all of the edit markup into a
 huge if/elseif/elseif block, which was reproduced in two or three places
 throughout BP. So replacing the markup through templates would have
 involved reproducing hundreds of lines of template code, spread out
 through several templates.

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5799#comment:3>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac