[wp-trac] [WordPress Trac] #35698: Distinguish between regular (site) options and network options in `sanitize_option()`
WordPress Trac
noreply at wordpress.org
Thu Apr 14 08:03:39 UTC 2016
#35698: Distinguish between regular (site) options and network options in
`sanitize_option()`
----------------------------------------+------------------------
Reporter: flixos90 | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: 4.6
Component: Formatting | Version:
Severity: normal | Resolution:
Keywords: has-patch needs-unit-tests | Focuses: multisite
----------------------------------------+------------------------
Comment (by flixos90):
Replying to [comment:14 jeremyfelt]:
> Would it be strange to do something like
`sanitize_{$context}_context_option_{$option}` to clarify that
sanitization is happening in a specific context?
Agreed, using `site_option` in the filter name would confuse a bit since
we (unfortunately) call network options this occasionally. :) In
[attachment:35698.4.diff] I applied this change.
> Another option may be to pass `$context` as another parameter to
`sanitize_option_{$option}` so that it's available for those who need it.
Core's use is probably more concerned with the actual `$context` parameter
and how that determines where to fallback when an error is encountered.
I prefer the solution of having the context in the filter name. If it was
a parameter, we would do a lot of `add_filter` just to return directly
when it doesn't have the context we expect. For example I could see
`register_setting()` to be network compatible at some point, in which case
it would use the new filter from here. If we just passed `$context` as a
parameter, this would cause problems because we couldn't add a filter
''only'' to a regular vs network option.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/35698#comment:15>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list