Opened 13 years ago
Closed 13 years ago
#3213 closed defect (bug) (fixed)
Can't save a profile field with special characters
Reported by: | javiervd | Owned by: | |
---|---|---|---|
Milestone: | 1.5 | Priority: | minor |
Severity: | Version: | 1.2.8 | |
Component: | Extended Profile | Keywords: | has-patch commit |
Cc: |
Description
I have a set of checkboxes set in a profile group some of them have the "&" character in the name, they get displayed fine on the page but can't save them. On the same group the ones with no special characters get saved just fine.
Attachments (1)
Change History (7)
#3
@
13 years ago
- Keywords has-patch needs-testing added; needs-patch removed
DJPaul, your suggestion that we should stop the checkbox name from being encoded on save is hard to implement. That field value is run through xprofile_sanitize_data_value_before_save(), which uses xprofile_filter_kses(), which uses wp_kses(), which uses wp_kses_normalize_entities(), which is where the & conversion is happening. We'd have to rebuild much of the kses process in order to skip this step in the sanitization routine.
Instead, I'm taking the opposite route, and filtering the allowed values through xprofile_sanitize_data_value_before_save() before comparing it against the submitted values. (This requires a tweak in the way that xprofile_sanitize_data_value_before_save() works.) I know that this is not ideal in the grand scheme of things, but I think it's the best practical solution, given the way that the rest of the xprofile data validation process works.
In 3213-1.patch, I've applied this fix. Please test.
Values are stored correctly, but they aren't being read properly on display; bp_get_the_profile_field_options(), around line 487. The & is stored as "&" in the database and it's being compared against "&". The "checkbox" db entry appears as the HTML entity, but the "option" values are stored as "&". Best fix is probably to stop the checkbox name being encoded (and do it on output rather than input).