[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      |
-----------------------------+------------------------------

Comment (by johnjamesjacoby):

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

 Completely. A good example is using an existing mobile front-end framework
 like Framework7 or Ionic, to fit into the expectations about what mark-up
 is necessary to fit form fields into themes nicely. Our core markup should
 be flexible, and easy to extend in the place where markup extension occurs
 -- the theme.

 We've worked hard to eliminate hard-coded mark-up in our core files to
 allow them to be as flexible as possible, and this is a step backwards. We
 moved markup from the theme where it belongs, into core files, and
 abstracted ideas into several nested (less easy to grok) methods that
 require complex theme-to-plugin inheritance across projects without
 adequate dependency management.

 What we have now is a mix of procedural function calls (like
 `bp_get_the_profile_field_is_required()`) and direct class method calls
 (like `get_edit_field_html_elements()`) that likely should have procedural
 wrappers, which also hugely prohibits the move back to template parts for
 field markup.

 Conceptually, modifying template output should only require template parts
 in a child theme. It should never require having several classes in
 functions.php.

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