register_setting() filter for sanitization callback needs to indicate 2 arguments accepted

[lumination]

register_setting() adds the function for sanitization of the option with the following line (wp-admin/includes/plugin.php):

add_filter( "sanitize_option_{$option_name}", $sanitize_callback );

For users wanting to declare a function for option sanitization, use of the option name within the function is sometimes desired, and is provided for in the filter application inside the sanitize_option() declaration as such (wp-includes/formatting.php):

$value = apply_filters("sanitize_option_{$option}", $value, $option);

With the filter always being applied with the option name as the second argument, I see no reason not to propose that the add_filter() call in register_setting() include "2" as the number of accepted arguments, allowing the option name to be passed.

[nacin]

It's not difficult to derive this from current_filter(). Seems sane though. Future pending patch.

[nacin]

This is an add_filter() call, not apply_filters(). So probably needs to be 10, 2.

[solarissmoke]

Oops, yeah, bit slow this morning :)

[ejdanderson]

Filter args as optional parameters.

[markjaquith]

This is a really lame omission. You should be able to have a generic save handler that does a switch on the option name and does your sanitization magic. 3.3-early, please.

+1 for solarissmoke's patch: 15335.2.diff

[markjaquith]

In [18887]:

Pass both parameters to the sanitize_option_FOO callback set in register_setting(). props lumination. fixes #15335

[duck_]

[18951] reverted [18887], see #18914.

Need to deal with back compat when using intval, for example, as a callback. See also #14671.

[nacin]

#26084 was marked as a duplicate.

[nacin]

Sorry for the noise.

[SergeyBiryukov]

#29193 was marked as a duplicate.

[ericlewis]

@duck_ said

Need to deal with back compat when using intval, for example

Sounds like this is a deal breaker.

[swissspidy]

Sounds like #14671 would need to be fixed first, although it seems like the reflection thing is out of the question. Thus, this ticket here would become a wontfix.

[peterwilsoncc]

#43629 was marked as a duplicate.

[peterwilsoncc]

Over in #43629, @seanleavey has suggested adding the priority and number of arguments accepted to the register_setting arguments. This could be a workaround for #14671.

This would require modification to unregister_setting removing the filter.

I'm undecided on the suitability of this solution.

[seanleavey]

Replying to peterwilsoncc:

Over in #43629, @seanleavey has suggested adding the priority and number of arguments accepted to the register_setting arguments. This could be a workaround for #14671.

This would require modification to unregister_setting removing the filter.

I'm undecided on the suitability of this solution.

It's not as nice as #14671's proposal, but it's better than nothing. Saying that, since WordPress 5.0 is round the corner, could this be the time to break backwards compatibility regarding intval as a filter? The message could just be: don't use intval and other functions that don't have a suitable signature for a WordPress sanitization filter.

[ocean90]

Since register_setting() now supports an $args argument, how about a sanitize_callback_accepted_args which defaults to 1 as seen in 15335.patch​?

[jlambe]

I was going to report this as well and I found this original issue on trac.

Just to go against the title issue, I suggest that the call to the add_filter( "sanitize_option_{$option_name}", $args['sanitize_callback']); (options.php - Line 2026 - WordPress 4.9.6) does define the 3 arguments provided by the apply_filters( "sanitize_option_{$option}", $value, $option, $original_value ); (formatting.php - Line 4314 - WordPress 4.9.6).

Indeed it is quite useful to get the setting name and it would make the code cleaner I suppose for some sanitization and validation on the server side.

+1 to finally get this one merged on next release please :)