Add 'default' to register_setting

[rmccue]

Imagine a future where you don't need to pass your default settings every time you call get_option. Instead, you simply pass into register_setting once.

Attached patch does this. Also moves the register_setting group of functions from wp-admin to wp-includes/option.php to allow usage everywhere, rather than just in the admin. This is probably a Good Idea with the changes made in #37885, as register_setting is now also useful for the REST API, not just the admin.

This does do some funky meta-programming that sucks a bit: if you call get_option( 'option_name' ) without a default parameter, it uses the registered default. If you call get_option( 'option_name', false ), it uses the value you passed in (false) even though this is the default parameter value. This isn't great, but allows us to do this nicely with backwards compatibility and is somewhat less surprising.

[rmccue]

As an example of how this works:

<?php

// Register the setting.
register_setting( 'rmccue', 'rmccue_some_setting', [
        'default' => 'yolo',
]);

var_dump( get_option( 'rmccue_some_setting' ) );
// => 'yolo'

var_dump( get_option( 'rmccue_some_setting', false ) );
// => false

var_dump( get_option( 'rmccue_some_setting', null ) );
// => null

[joehoyle]

This looks good to me, +1 on the moving of the function too - right now I'm having to manually include the admin file when we want to use register_setting outside of the admin, which is fairly common now with the additions.

[rmccue]

Add parameter to missed filter

[rmccue]

Going to move the settings functions in #37885 instead of here.

[jorbin]

With the moving of the functions done in [38687], this needs a refresh.

[joehoyle]

I somewhat interesting and controversial idea suggested by @jorbin is to _deprecate_ the $default argument for get_option() and instead recommend the use of register_setting, as in (I think) virtually all cases, one would want a consistent default for their options, and it leads to developer error by having to re-specify the default on every get_option call.

I think this would be a pretty good idea, however is a small but wide impacting change, and I'm not sure that going this far is required just to support the default argument in register_setting. How about we start with adding it to register_setting but leave the deprecation of default in get_option for down the road?

[jtsternberg]

Refreshed patch (now that functions have been moved to different file)

[joehoyle]

In 38910:

Options: Add 'default' to register_setting

Add a default argument to register_setting that will be used an the default option value viet get_option() in the event of no other option being specified. This means (if chosen) developers can define their default once via register_option and not have to duplicate the value every time they make a call to get_option().

Props rmccue, jorbin, jtsternberg.
Fixes #38176.

[jeremyfelt]

The default_option_ filter in update_option() does not pass a third parameter, which the filter_default_option() function requires. See ​https://travis-ci.org/aaronjorbin/develop.wordpress/builds/170519570

[jeremyfelt]

38176.5.diff​ adds false as the third parameter when applying the default_option_ filter in update_option(). This seems like the right assumption to make here.

This resolves the errors in the tests.

[jeremyfelt]

In 38916:

Options: Make $passed_default available in remaining default_option_{$option} filter.

Pass false as the $passed_default value when the default_option_{$option} filter is applied in update_option as no default is ever passed.

This resolves an error in tests where the 3rd parameter is not available to filter_default_option().

Fixes #38176.

[ocean90]

In 39382:

Options: Pass the $passed_default parameter to the 'default_option_{$option} filter in add_option().

This was missed in [38910].

Props joehoyle, lucasstark.
See #38176.
Fixes #38930.

[ocean90]

In 39383:

Options: Pass the $passed_default parameter to the default_option_{$option} filter in add_option().

This was missed in [38910].

Merge of [39382] to the 4.7 branch.

Props joehoyle, lucasstark.
See #38176, #38930.

[johnbillion]

In 42659:

Options: Use more appropriate language in the test suite.

See #43207, #38176

[jorbin]

In 42663:

Options: Use most appropriate language in the test suite.

The test suite's opinion of cancer should be clear.

Reverts r42659.

See #43207, #38176

[helen]

In 42667:

Options: Use strings in the test suite that follow community guidelines.

Also somewhat explain to future maintainers why this pairing of strings was chosen, besides this committer's musical preferences. Social opinions on cancer are fairly clear, as are commonly accepted definitions of profanity and family-friendly language.

Shout out to the close contender, which would have been particularly appropriate here: "You could be the king But watch the queen conquer".

see #43207, #38176

[desrosj]

As far as I can tell, a dev note was never published for this change. Removing the needs-dev-note keyword.