[wp-trac] [WordPress Trac] #16939: When using `add_settings_error()` with the Settings API, I should have the option to NOT update options unless there are no errors.

[WordPress Trac]

#16939: When using `add_settings_error()` with the Settings API, I should have the
option to NOT update options unless there are no errors.
-----------------------------+-------------------------------------
 Reporter:  philipwalton     |      Owner:
     Type:  feature request  |     Status:  new
 Priority:  normal           |  Milestone:  Awaiting Review
Component:  Plugins          |    Version:  3.1
 Severity:  normal           |   Keywords:  2nd-opinion ux-feedback
-----------------------------+-------------------------------------
 As I understand it, with the Settings API the $value returned by the
 validation function will always be used to update the options table via
 `update_options('option_name', $value)`. If you want to reject a
 particular piece of user input, the best you can do is set it to the
 previous value and add an error message, but regardless, the entire option
 $value will be updated in the database.

 This is not ideal.

 Imagine a situation where a plugin author wants to accept a submitted form
 '''only''' if all fields pass validation. For example, imagine the
 following (completely fictitious) settings page:
 {{{
 Name:     ___________
 E-mail:   ___________
 Phone:    ___________
 }}}
 The user fills out this information, clicks submit, but his email address
 is invalid. At this point the plugin developer has a few options, none of
 which are great. (1) Update the option with the correct name and phone
 fields but leave the email blank and show an error message. (2) Update the
 option with the exact information the user entered but still show an error
 message about the email. (3) Update the option with empty strings or null
 (which would leave all form fields blank) and show the error message.

 The problem is that all of these options still require creating a record,
 potentially a record that is incomplete. If the user gets the error
 message and then his computer freezes before he has a chance to correct
 the error, suddenly my database has bad data.

 I think a better method (and the way most PHP frameworks do it) would be
 to do validation on the raw data from the `$_POST` variable and then,
 based on those results, allow the developer to choose to either run
 `update_option()` or not. If there are still errors, there would need to
 be some way to access the data the user submitted so the form fields could
 be populated and no retyping would be required. Currently, because of a
 redirect, the `$_POST` variable is cleared when you get to the page where
 the error message is presented. Perhaps a function like
 `get_settings_error_data()` could be implemented.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/16939>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software