[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:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  2.2
Component:  XProfile     |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |
-------------------------+------------------
Changes (by boonebgorges):

 * keywords:  has-patch 2nd-opinion => has-patch


Comment:

 needle - Thanks for the revision. 5625.03.patch makes the following
 changes:

 - Replace your settings check with a function
 `bp_xprofile_is_richtext_enabled_for_field()`
 - Tear out the settings stuff. We don't support the display of media at
 this time, so I can't think of any reason to allow it to be turned on in
 the UI. I can't think of a reason why we'd want Quicktags ever to be off.
 And, as I suggested earlier, I can't really come up with a good reason why
 anyone would want to turn richtext off in general.
 `bp_xprofile_is_richtext_enabled_for_field()` has a filter - if people
 want it disabled for some reason, they can use that. But I'd wager that'll
 be < 5% of all installations.
 - Remove sanity checks. Given the way these methods are called, I can't
 see any way that they would ever fail.
 - Codestyling

 I'm not 100% clear on the display_filter() and get_field_data() stuff, so
 I didn't touch that logic for the time being. But I will note that it's
 pretty hackish indeed, and we've got to find a better solution. There seem
 to be a couple things going on:

 1. You don't like the auto-linking of
 `xprofile_filter_link_profile_data()` on rich text. I'm not sure I follow
 this one - I messed with it a little and it seemed fine to me.
 2. You want to get raw data in edit mode (`add_filter(
 'xprofile_get_field_data', array( $this, 'get_field_data' ), 15, 3 );`).
 But don't we already get that? When I comment out this line, everything
 seems to look OK to me. Can you give the specifics of what you're
 attempting to prevent?
 3. Certain display filters must be turned off in order for HTML to be
 displayed properly - in particular, I think, `esc_html()`. But if that's
 what we want, then we should just `remove_filter()`, or change our
 `add_filter()` call to a wrapper function that only adds the filter
 conditionally. Put another way - your patch is approaching this problem
 like a plugin author (not touching other core files), but a core patch is
 allowed to touch core files ;)
 4. The technique you're using appears to wreck line breaks.

 My gut feeling is that we should tear out your display_filter and
 get_field_data stuff, and fix what remains of the problems (specifically
 3, but maybe also 1) removing the specific filters that are problematic.
 But before patching this, I wanted to get your feedback, and maybe some
 more details on the problems you were trying to solve there.

 Thanks again! This is going to be a great feature.

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