REST API: admin_email setting description is inaccurate

[johnbillion]

The description field for the admin_email setting has been copied from the Multisite description (1). The description and the behaviour of this field in the admin area actually differs between single site and Multisite (2).

Not strictly related to the REST API, but the setting was introduced for it.

(1) https://core.trac.wordpress.org/browser/trunk/src/wp-includes/option.php?rev=39335&marks=1751-1760#L1750
(2) https://core.trac.wordpress.org/browser/trunk/src/wp-admin/options-general.php?rev=39335&marks=81-83,100-102#L80

[ocean90]

38990.diff​ uses is_multisite() to change the message based on context.

[rachelbaker]

+1 on 38990.diff​

[rachelbaker]

In 39406:

REST API: Correct the admin_email setting description for single site installs.

Display different descriptions for multisite or single site installations.

Props johnbillion, ocean90.
Fixes #38990.

[rachelbaker]

In 39407:

REST API: Correct the admin_email setting description for single site installs.
Display different descriptions for multisite or single site installations.

Props johnbillion, ocean90.

Merges [39406] to the 4.7 branch.
Fixes #38990 for 4.7

[johnbillion]

Turns out the issue is a little more complex.

On Multisite, the admin_email input field is actually for an option named new_admin_email which gets set immediately when the form is saved. Only after the user clicks the link in their confirmation email, does the actual admin_email option get updated.

The REST API should use this same model to prevent users from accidentally changing their email address to something invalid.

[netweb]

Noting r39406 resulted in a string change, Slack discussion ​here

[rachelbaker]

On Multisite, the admin_email input field is actually for an option named new_admin_email which gets set immediately when the form is saved. Only after the user clicks the link in their confirmation email, does the actual admin_email option get updated.
The REST API should use this same model to prevent users from accidentally changing their email address to something invalid.

Hmm.. @joehoyle any thoughts on how we should approach this?

[joehoyle]

On Multisite, the admin_email input field is actually for an option named new_admin_email which gets set immediately when the form is saved. Only after the user clicks the link in their confirmation email, does the actual admin_email option get updated.

I'm not totally sure why this exists in multisite and not in single site?

On the assumption that we want to continue with that, we probably need to run a custom update hook by using rest_pre_update_setting which I guess if you try to update it on multisite it will noop the update, and instead trigger the confirmation email. How does that sound? I can put together a patch.

[nacin]

For the record - I don't see a string change here. [39406] appears to use the existing multisite and single site strings.

I'm not totally sure why this exists in multisite and not in single site?

This only existed in MU. This is probably one of those features that should *not* have been merged into core at all, but that ship sailed nearly seven (!?) years ago.

As for fixing this - I would suggest just pulling this setting for 4.7 and fixing it properly in 4.7.1 or 4.8.

[nacin]

FWIW, admin_email isn't in XML-RPC.

[helen]

Leave for single site and remove for multisite?

[nacin]

Replying to helen:

Leave for single site and remove for multisite?

Sure.

[nacin]

In 39470:

REST API: Register the admin_email setting in single site only.

fixes #38990.

[nacin]

In 39471:

REST API: Register the admin_email setting in single site only.

See [39470]. This time including unit test changes.

fixes #38990.

[nacin]

In 39472:

REST API: Register the admin_email setting in single site only.

Merges [39470] and [39471] to the 4.7 branch.

fixes #38990.