When using `add_settings_error()` with the Settings API, I should have the option to NOT update options unless there are no errors.
|Reported by:||philipwalton||Owned by:|
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.