[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 DJPaul):

 In class-bp-xprofile-field-type-textarea.php line 29, you set `type =
 textarea` and check for it later in bp-xprofile-functions.php line 1047
 (line numbers taking from viewing the patch file on Trac). Unless I'm
 misreading this, in the first instance you're setting the type on the
 `BP_XProfile_Field_Type` class (such a property isn't declared) and you
 are reading it from a `BP_XProfile_Field` (where such a property *is*
 declared).

 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.

 I was going to suggest moving the allowed_kses customisations into the
 field_type somehow because, again, it's information about a field type,
 and not a specific instance of a field. 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, a little like what we are proposing
 here.

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