[wp-trac] [WordPress Trac] #21989: update_option() calls sanitize_option() twice when option does not exist
WordPress Trac
noreply at wordpress.org
Mon Jul 7 02:34:52 UTC 2014
#21989: update_option() calls sanitize_option() twice when option does not exist
--------------------------------------------------+------------------
Reporter: MikeSchinkel | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: 4.0
Component: Options, Meta APIs | Version:
Severity: normal | Resolution:
Keywords: dev-feedback has-patch needs-testing | Focuses:
--------------------------------------------------+------------------
Comment (by rmccue):
Just hit this myself.
Disagree with nacin that it's the developer's responsibility to check
this. If I do something like `register_setting( 'group', 'opt_name',
'nonidempotent_func' )`, it doesn't make sense to me that the first save
(that creates the option) should behave differently to the second save
(that updates the option). As far as I'm concerned as the API user, I
shouldn't need to worry whether it's using `add_option` or `update_option`
internally.
Both totels and ddb's patches break backwards compatibility with the
`pre_update_option_{$option}` and `pre_update_option` filters, which
currently always get called when using `update_option`. However, both
operate on the sanitized version of the value, so using them would be
strange.
Choices I can think of, in preferred order:
1. Add extra parameter to `add_option` to skip sanitization: patch inbound
2. Skip the `pre_update_option` filters when adding options via
`update_option` (should probably add `pre_add_option_{$option}` and
`pre_add_option` filters as well; this also breaks BC with the filters):
[attachment:21989.diff] handles this
Thoughts? It'd be nice to fix this.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/21989#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list