format of user_email field

Use the ‘is_email’ filter. Your callback will probably get a ‘local_invalid_chars’ failure. In such a case, strip out the angle brackets and preceding text, remove your filter or otherwise prevent it from being called in a subsequent pass, and run the raw email address through is_email() again. If this fails, or the original failure was not ‘local_invalid_chars’, pass through the failure.

If the second pass is successful, return the original email with angle brackets and preceding text. In any case, add your filter back in again or otherwise enable it being called again for the next round.

I know wp_mail() accepts the angle bracket format, I’m not so sure of the parenthesis variant, so there may not be any point in allowing it with is_email().

Why is is_email() so restrictive? I cannot speak for core developers, but I believe the intent was always to conservatively start with not allowing anything, then progressively allowing things that are easy to check that will cover 95% of email address forms. Those in the 5% range are expected to use the ‘is_email’ filter to allow what ever it is they need. Most glaringly, no internationalized domain names are passed by is_email().

The biggest reason that is_email() doesn’t allow things in the way that you’re trying to is that the name portion (before the opening <) would always be taken from another area, like the users name or the systems name or something. It isn’t part of the actual email address and as such it shouldn’t be stored as part of the email address.

I know from experimenting using phpmyadmin that if I plant email addresses in the form rob([email protected]) in the user_email field of the wp_users table, the email works ok. However if I present such an email to the pods add function to the extended user pod the parenthenses are stripped out before storing in the database. Can I prevent or modify this sanitisation? I’ve searched the pods code and cannot identify the culprit. It has happened before the pre_user_email hook.

You never mentioned about Pods before, so of course we wouldn’t have thought of that ??

You’d get the best results aksing in the support forum for that plugin.

Thanks. I didn’t know if pods was relevant at the time. My question has drifted into pods territory. I was reluctant to cross post as that tends to irritate people. Sorry.

Pods uses is_email too, but it is restricted more than core in that it strips out non-allowed characters during processing, then it validates.

This use case is not supported and probably won’t be. Best bet is to use a different add user form that’s not using a Pods form.

Many thanks Scott but I am using a gravity form and a text field (ie not an email field) for the email and validating it myself so what I present to the pods add or save method has not been stripped of (). The stripping happens later before it is stored in the database. If I use the same code to plant the same info in a different pod ie anything other than the user pod then the stripping does not happen. This makes me feel that the problem is a core one not a pod one ie the core protecting the user_email field . Does that sound plausible?

Regards,

Rob

Have you done any de-bugging to find out exactly where the extra text is being stripped? That can be as easy as adding something like

echo "<p>Email at *CODE LOCATION*: '".$email."'</p>";

Take something like that and plant it everywhere through the code that the email address is passing through. That will show you what you want to see, and you can go back and remove them all when you’re done.

That will solve the biggest problem that you’re facing – you don’t know which part is actually causing your issue.

Aha I’ve found it by scanning the code with a free text editor. The culprit is sanitize_email() in wp-includes/formatting.php. I tried the rough bodge of replacing it with a null function returning the input $email unchanged. Unfortunately I can’t see how to replace this function by one more to my taste without hacking this file. Could anyone advise me how best to proceed?

Regards and many thanks for everyone’s help so far,

Rob

The ‘sanitize_email’ filter does not make available the unaltered email if it passes all other checks and is merely stripped of invalid characters. Thus, to meet your needs, this function cannot be used at all. It appears you would need to store your emails as plain text, not as an email address. You of course would need to do your own sanity checks.

It should be possible to use one of the wp_mail filters to discard the passed email address and substitute the one from your text field when actually sending an email.

I’ve now solved the problem from my point of view by using the pre_user_email filter to substitute the original email (already validated and passed via the $_GET global) whenever the filter is called with a non-null WP sanitized email. This ensures that the original email is stored in the database uncorrupted. Thanks again for all who tried to help.