Allow settings to be updated and read.

[spacedmonkey]

Working on #48885. Decided to go a different direction than the ticket name. Use the existing endpoint but add some new callbacks.

To use this PR, here is the example I use to test.

add_action('init', function(){
	register_setting(
		'general',
		'wibble',
		array(
			'show_in_rest' => array(
				'name' => 'wibble',
				'edit_permission_callback' => '__return_true',
				'read_permission_callback' => '__return_true',
			),
			'type'         => 'string',
			'description'  => __( 'Site title.' ),
		)
	);
});

This make a setting called wibble, that will now be public to read and edit. You never do this, but it gives you an idea of how the code works.

Trac ticket: https://core.trac.wordpress.org/ticket/48885

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[anton-vlasenko]

Please find my review notes below. Thank you.

[anton-vlasenko]

In my testing, this test didn't work because the user's capabilities were cached. Therefore, I had to reorder it like this to make the test work:

Suggested change

	wp_set_current_user( self::$administrator );
	$user = get_user_by( 'id', self::$administrator );
	$user->add_cap( 'custom_rest_cap' );
	$user = get_user_by( 'id', self::$administrator );
	$user->add_cap( 'custom_rest_cap' );
	wp_set_current_user( self::$administrator );

[anton-vlasenko]

Same.

Suggested change

	wp_set_current_user( self::$administrator );
	$user = get_user_by( 'id', self::$administrator );
	$user->add_cap( 'custom_rest_cap' );
	$user = get_user_by( 'id', self::$administrator );
	$user->add_cap( 'custom_rest_cap' );
	wp_set_current_user( self::$administrator );

[anton-vlasenko]

The WP_Test_REST_Settings_Controller::test_update_item_with_edit_permission_callbacks() test method implies that the setting can be updated even if the current user lacks the manage_options capability. However, the test fails because the code still checks for that capability.
I'm not sure what the intention is here: should a user be able to update a setting even without the manage_options capability, as long as the permission callback allows it?

Suggested change

	}
	}
	return true;

[anton-vlasenko]

Nitpick:

Suggested change

	* @return true|WP_Error True if the request has access to update the item, WP_Error object otherwise.
	* @return bool|WP_Error True if the request has access to update the item, WP_Error object otherwise.