Issue with the backslash character in xprofile admin

[dontdream]

Steps to reproduce:

1. Create a Radio Buttons xprofile field
2. Add the option O'Hara
3. Save the field
4. Reopen the field for edit
5. The option is now O\'Hara

If you save again and reopen for edit, two more backslashes will be added, and so on indefinitely.

[imath]

Hi dontdream

Thanks a lot for your feedback.

There may be a more elegant way, but simply stripslashing the value is fixing this.

[boonebgorges]

I'd like to see a more thorough examination of what's going on here. At the very least, we should be stripping slashes further up the chain - maybe in BP_XProfile_Field::get_children()? In theory, we should not be saving slashed data in the first place; see #2776. This ticket is maybe not the place to solve the entire problem, but could we at least have a closer look at why this particular piece of data is ending up slashed in the first place?

[DJPaul]

Also interesting to know if this is a regression or not.

[imath]

Replying to DJPaul:

Also interesting to know if this is a regression or not.

I confirm it's a regression from 1.9. Just checked 1.9.2, and in BP_XProfile_Field->render_admin_form_children() the value was stripslashed:

<input type="text" name="<?php echo esc_attr( $type ); ?>_option[<?php echo esc_attr( $j ); ?>]" id="<?php echo esc_attr( $type ); ?>_option<?php echo esc_attr( $j ); ?>" value="<?php echo stripslashes( esc_attr( $options[$i]->name ) ); ?>" />

Replying to boonebgorges:

In theory, we should not be saving slashed data in the first place

Well a filter is available so we can stripslash the array of options before saving it to db.
see 5704.02.patch

[DJPaul]

Cool, any attempts to un-slash the data should be dealt with in the other ticket, and that's a giant piece of work.

[boonebgorges]

For the 2.0.x series, let's fix the regression and put the stripslashes() back where it was before.

We should be stripslashing on the way in, but 5704.02 is probably not the best way to do it. (1) we don't have to use filters, because we are the core developers :) And (2) we should be stripping intelligently: slashes would come from POSTed data, so we should be stripping at the point that $_POST is parsed.

[djpaul]

In 8650:

xProfile admin: correctly stripslash data for children field options.

This was a regression introduced 2.0 with the profile field types rewrite.
Fixes #5704, props imath

[djpaul]

In 8651:

xProfile admin: correctly stripslash data for children field options. (branch)

This was a regression introduced 2.0 with the profile field types rewrite.
Fixes #5704, props imath