[wp-trac] [WordPress Trac] #34893: Improve Customizer setting validation model

[WordPress Trac]

#34893: Improve Customizer setting validation model
-------------------------------------+--------------------------
 Reporter:  westonruter              |       Owner:  westonruter
     Type:  enhancement              |      Status:  accepted
 Priority:  normal                   |   Milestone:  4.5
Component:  Customize                |     Version:  3.4
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:  javascript
-------------------------------------+--------------------------

Comment (by westonruter):

 Replying to [comment:5 joehoyle]:
 > @rmccue and myself have discussed for the REST API on Save, whether the
 validate callback should be called on the value pre or post sanitize. I
 think there's merit to both, depending on the use case, we never came to a
 hard decision on that, but core currently calls sanitize before validate.
 This means the validator function can deal with "clean" data, and is
 concerned with specific validity rather than type checks. For this way
 round, the example of posts_per_page is a good one: `sanitize_callback`
 calls `absint` on the data passed via POST, and the `validate_callback`
 would then `> 0 && < 100`.

 What about if the original raw unsanitized value is passed into the
 validator along with the sanitized value? This would allow the validator
 to have the flexibility to determine whether or not the sanitized value
 can be considered “good enough” for persisting to the DB, or else it can
 do a strict check to fail it simply if `$sanitized_value !==
 $unsanitized_value`.

 In that regard, the patch for this ticket could be modified to pass in
 both the `$unsanitized_value` and the `$unsanitized_value` to the
 `customize_validate_{$setting_id}` filter. I've amended my patch to
 implement that: [attachment:34893.1.diff]. It also adds:

 * Adds a `$strict` second parameter to `WP_Customize_Setting::save()`,
 which is a signal that `WP_Error` can be returned
 * Validate all settings before the `customize_save` action, and return
 with a JSON error with an array of all the invalid settings if any are
 invalid.

 For the REST API, however, it doesn't look like the
 original/raw/unsanitized value would still be available for the validate
 callback to look at?

--
Ticket URL: <https://core.trac.wordpress.org/ticket/34893#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform