Implement email sanitize in REST API

[spacedmonkey]

Implement email sanitize in REST API over just using sanitize_text_field

[TimothyBlynJacobs]

Is this stricter than sanitize_text_field? If so, I think we'd want to make sure it isn't stricter than is_email would allow, right?

Separately, as I understand it, filter_var historically hasn't been used in WordPress since I think it can be disabled and we don't list it as a required extension.

Cc: @SergeyBiryukov, @jrf.

[spacedmonkey]

filter_var is used ​elsewhere in core.

sanitize_text_field is applied to emails first then filter_var is run. The idea is to just remove character that are not valid in an email. It doesn't do a lot of validation that is_email, checking domain length etc.

[TimothyBlynJacobs]

Does that line actually get executed? It looks like it prefers regex which I think needs to be available to run WP?

Related #28170, #16867

The idea is to just remove character that are not valid in an email.

Right, what I'm trying to figure out, is if there is a case where the sanitization would not allow an email that would have previously been allowed by is_email(). I understand filter_var doesn't do the complex checking is_email does. But I'm wondering if any of the characters it strips would've been allowed by is_email.

[spacedmonkey]

I am not locked to using filter_var. Regex will work just as well.

[kadamwhite]

@SergeyBiryukov After discussion in the REST API weekly meeting we'd love to get your eyes on this briefly, it'd make us more confidant in the solution

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

@TimothyBJacobs @spacedmonkey this is the refreshed work of patch attached into Trac ticket. Based on your discussion I've ported behaviour of filter_var into PHP code. Additionally I've added an extra check to avoid sanitization of email when is_email function returns true what is most likely an indicator that value is recognized correctly and doesn't need to be sanitized.

Please let me know if you have any questions.