[wp-trac] [WordPress Trac] #21989: update_option('example') calls sanitize_option('example') twice when false===get_option('example')

[WordPress Trac]

#21989: update_option('example') calls sanitize_option('example') twice when
false===get_option('example')
-------------------------------------------------+-------------------------
 Reporter:  MikeSchinkel                         |       Type:  defect
   Status:  new                                  |  (bug)
Milestone:  Awaiting Review                      |   Priority:  normal
  Version:                                       |  Component:
 Keywords:  needs-patch dev-feedback 2nd-        |  Administration
  opinion                                        |   Severity:  normal
-------------------------------------------------+-------------------------
 I just spent several hours tracking down an issue when using the Settings
 API where `sanitize_option()` is called twice which is unnecessary
 execution especially if sanitization includes calling an external API for
 username/password authorization ''(this was how another developer set it
 up for a plugin I was debugging.)''

 What happens is that a call to `update_option()` will call
 `sanitize_option()` and then if the option wasn't previously in the
 options table `update_option()` will delegate to `add_option()` which
 calls `santize_option()` a second time.  This would normally be easy to
 workaround by first calling `get_option()` and testing for `false` and
 calling `add_option()` instead of `update_option()` if `false`, but not
 when the Settings API chooses how to call it.

 I've looked at the problem and can envision several different ways to
 solve it such but don't know which the core developers would choose ''(or
 if they'd choose yet another option I haven't envisioned)'' so I didn't
 submit a patch:

 - Adding a 3rd parameter `$mode` to `sanitize_option()` that identifies
 the mode ''('add', 'edit', default = 'unknown')'' and thus allow the hook
 to ignore one of the options ''(this would be more backward compatible but
 would put the onus on the developer to know to do this)'',
 - Adding a 5th parameter `$bypass_sanitize` to `add_option()` defaulted to
 `false` that is only passed as `true` in `update_option()` allowing
 `update_option()` to disable the call to `sanitize_option()` found in
 `add_option()` ''(this would be less backward compatible and hacky, but
 seemless to the developer)''
 - Adding a 3rd parameter `$bypass_sanitize` to `update_option()` defaulted
 to `false` that is only passed as `true` from `/wp-admin/options.php`
 allowing `update_option()` to bypass the call to `sanitize_option()` if an
 `add_option()` will happen ''(this would be less backward compatible and
 hacky, but seemless to the developer)''
 - Have `/wp-admin/options.php` test for no pre-existing option and then
 call `add_option()` or `update_option()`, respectively ''(this would be
 seemless to the developer but less backward compatible and not hacky, and
 it wouldn't handle the general case.)''

 So is this worth fixing to save other users and developers debugging time,
 and to reduce the chance of subtle errors in new code? If yes, how best to
 approach?

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