[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 04:31:15 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 Denis-de-Bernardy):
Replying to [comment:11 rmccue]:
> 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.
Hold... Did you just seriously argue that maintaining backwards compat on
broken was important? ;-)
> Choices I can think of, in preferred order:
>
> 1. Add extra parameter to `add_option` to skip sanitization:
[attachment:21989.2.diff] handles this
> 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.
I for one ink that adding a new argument borders on crazy, so I'd rather
see my own patch get checked in.
As an aside, don't miss what I highlighted as I submitted it: the order of
these filters and such differ in update_option and update_site_option --
and other options and transient related functions, for that matter.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/21989#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list