#37247 closed defect (bug) (fixed)
Sanitization needs to come after validation in WP_Customize_Manager
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 4.6 | Priority: | normal |
Severity: | normal | Version: | 4.6 |
Component: | Customize | Keywords: | has-patch has-unit-tests |
Focuses: | Cc: |
Description
In WP_Customize_Manager
, the following methods validate after sanitizing:
post_value()
validate_setting_values()
Validation is checking whether the input is valid according to business rules. Sanitization is transforming the input to make it ready to be persisted.
The order in which they are used within the above methods, apart from just conceptually being the wrong way around, might cause a valid input to fail validation because the sanitization had already changed it.
Related to #37192
Attachments (2)
Change History (8)
#1
@
9 years ago
- Milestone changed from Awaiting Review to 4.6
- Owner set to westonruter
- Status changed from new to accepted
- Version set to trunk
Note: See
TracTickets for help on using
tickets.
@schlessera great observation. This is something I debated quite a bit, and I went with the current sanitize > validate scheme because the REST API was doing the same. Now that the order of operations is being changed in #37192, I agree that the Customizer should be aligned. Note, however, that the Customizer's implementation allowed for the
sanitize
callbacks to also returnWP_Error
instances, thus allowing the sanitize callbacks to also perform validation since the two are often very closely related. A sanitize callback can return aWP_Error
in the case where the value being sanitized is “too far gone” to be recovered for the purposes of passing through and needs to be be flatly rejected (marked as invalid).