[buddypress-trac] [BuddyPress Trac] #5625: Use wp_editor for "multi line text area" xprofile field in frontend
noreply at wordpress.org
Sat Sep 27 03:01:57 UTC 2014
#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
needle - Thanks for the revision. 5625.03.patch makes the following
- Replace your settings check with a function
- 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.
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/>
More information about the buddypress-trac