[wp-trac] [WordPress Trac] #43208: Separate setting validation from sanitization

[WordPress Trac]

#43208: Separate setting validation from sanitization
-------------------------------------------------+-------------------------
 Reporter:  flixos90                             |       Owner:
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
Component:  Options, Meta APIs                   |  Review
 Severity:  normal                               |     Version:
 Keywords:  2nd-opinion has-patch needs-unit-    |  Resolution:
  tests                                          |     Focuses:
-------------------------------------------------+-------------------------
Changes (by flixos90):

 * keywords:  2nd-opinion has-patch => 2nd-opinion has-patch needs-unit-
               tests


Comment:

 [attachment:43208.2.diff] is a cleaner approach to separating validation
 from sanitization. It introduces a function `validate_option( $option,
 $value )`, that consists of a filter to perform setting validation, which
 was inspired by the existing Customizer logic following a similar purpose.
 A validate callback can be provided intuitively via `register_setting()`.
 Benefits:

 * Validation is not tied into updating the option. This allows for
 flexible handling: First, check if the value is valid. Then, if invalid,
 cancel the process, or if valid, proceed with updating the option.
 * No backward-compatibility issues, as it's a new function. Validation of
 core options that were previously handled in `sanitize_option()` should
 remain that way.

 Of course, just having the function there won't actually provide a huge
 benefit. Therefore [attachment:43208.3.diff] contains implementation of
 the integration points, which are:

 * Updating an option via a settings page submission (`src/wp-
 admin/options.php`).
 * Updating an option from the Customizer (`src/wp-includes/class-wp-
 customize-setting.php`).
 * Updating an option via the REST API (`src/wp-includes/rest-api/endpoints
 /class-wp-rest-settings-controller.php`).

 This makes handling feedback about validation errors simple and
 straightforward. The REST API previously didn't handle this at all, for
 settings page submissions it was achieved in a somewhat hacky way by using
 `sanitize_option()` and calling `add_settings_error()` from there. The
 Customizer was the only location already handling validation properly,
 however even here there's now the benefit of having a uniform way to
 register validation for settings. Validation callbacks specific to the
 Customizer will still fire, so it's fully backward-compatible.

 @joehoyle @johnjamesjacoby @SergeyBiryukov Would like to have your
 feedback on this approach. Any objections/considerations? I'll work on
 unit tests for this too, if it's a viable approach.

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