[wp-trac] [WordPress Trac] #21989: update_option('example') calls sanitize_option('example') twice when false===get_option('example')
WordPress Trac
wp-trac at lists.automattic.com
Tue Sep 25 05:04:35 UTC 2012
#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
More information about the wp-trac
mailing list