[buddypress-trac] [BuddyPress Trac] #5625: Use wp_editor for "multi line text area" xprofile field in frontend

[buddypress-trac]

#5625: Use wp_editor for "multi line text area" xprofile field in frontend
-------------------------------------+---------------------------
 Reporter:  sooskriszta              |       Owner:  boonebgorges
     Type:  enhancement              |      Status:  assigned
 Priority:  normal                   |   Milestone:  2.4
Component:  Component - XProfile     |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |
-------------------------------------+---------------------------

Comment (by boonebgorges):

 > Having bp_xprofile_is_richtext_enabled_for_field decide if a field
 supports rich HTML seems like the wrong place. I think that information
 should go in the field_type somewhere because it affects how the field is
 rendered, obviously.

 > Once of the goals and wins behind the introduction of the field_type
 classes a few releases ago was to centralise all the information about
 that field_type and avoid special-case logic littered throughout BP

 I agree with this in principle. But richtext is a feature that (a) might
 be shared by more than one field type, and (b) should be toggle-able (at
 least via filter) for individual fields, so that you can have a specific
 textarea field with richtext disabled. As for (a), we can probably squeeze
 some sort of richtext logic into the `BP_XProfile_Field` base class,
 though it's going to be unused by all fields but 'textarea'. As for (b),
 the field type objects generally don't know anything about the fields that
 instantiate them, so I'm not sure of a non-hack workaround for it.

 DJPaul - Do you have specific suggestions for how the proposed improvement
 can be fit into the field_type infrastructure, without sacrificing either
 (a) and (b), while remaining true to the original vision of field types?
 I'm struggling to think of anything that seems less than arbitrary, and I
 don't want this very nice improvement to be held up out of aesthetic
 concerns over code organization.

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