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

 DJPaul - Disregard most of the last comment. It's inaccurate and kinda
 snotty :)

 The one part that's true is that richtext support should be a property of
 *fields*, not *field types*. It is, of course, the field type that
 supplies the markup; and the field type will determine the default
 richtext setting for a given field; but it's a setting that should
 ultimately be the responsibility of the field itself.

 [attachment:5625.3.diff] modifies the approach a bit by introducing
 `supports_richtext` as a property of field types, in the same way that
 `supports_options` and other field type properties set certain defaults
 for fields. Then, in `bp_xprofile_is_richtext_enabled_for_field()`, I fall
 back on that value, if found. This is a bit better than the previous
 technique. In theory, this check might become a method on
 `BP_XProfile_Field` instead of a function, but we don't really do this
 anywhere else, so I figure it's an odd construction to introduce just for
 this feature.

 > 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.

 I haven't touched this in the latest patch. I don't necessarily agree that
 allowedtags is *essentially* a property of the field type, though I do
 think (as above) that the field type should be able to set the default
 allowedtags value for fields of the type. But I wasn't sure the pattern
 that would make the most sense, given that only textareas support richtext
 out of the box. Perhaps there's a
 `BP_XProfile_Field_Type_Textarea::filter_allowed_tags()` callback that
 does what I've currently put into `xprofile_filter_kses()`? How and when
 does the field type `add_filter()`? I would personally be OK with not
 solving this larger architectural problem for v1 of the feature, but if
 you have an idea for how it might look, I'd be happy to hear it.

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