[buddypress-trac] [BuddyPress Trac] #5625: Use wp_editor for "multi line text area" xprofile field in frontend
buddypress-trac
noreply at wordpress.org
Wed Oct 7 18:24:12 UTC 2015
#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 |
-------------------------------------+---------------------------
Changes (by boonebgorges):
* keywords: has-patch => has-patch needs-testing
Comment:
[attachment:5625.2.diff] is (I think) a working implementation.
I've reworked needle's original patch so that
`BP_XProfile_Field_Type_Textarea` no longer needs to do a bunch of tricks
to jump through filter hoops. For one thing, that technique involved
adding, removing, and stacking filters in a way that created unnecessary
complication. For another, it limited richtext fields to textareas only -
a restriction that seems appropriate by default, but should not be
enforced strictly.
The most important addition here is `bp_xprofile_escape_field_data()`. I'm
using this instead of `esc_html` when filtering field data for output. If
richtext is enabled for the field, the data is run through kses; if not,
it's run through `esc_html()` like before.
The other changes of note are related to editor CSS. I made a few changes
to make it look OK in our default templates. This meant removing the
top/bottom padding from the `textarea` in 'Text' mode (it looked weird
when switching between modes), and making buttons a bit narrower so that
they squeeze into a single row on most themes. hnla and others, please let
me know if this will break anything.
--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5625#comment:24>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac
More information about the buddypress-trac
mailing list