A call for testing of newly merged Unicode email address support in WordPress, introducing changes that allow WordPress accounts to use email addresses containing non-ASCII characters. The update enables is_email() and sanitize_email() to accept such addresses on sites using utf8mb4 databases and introduces a new WP_Email_Address class.
Background on the Unicode email proposal
The testing effort follows a proposal published last month by Arnt Gulbrandsen, who argued that WordPress has not kept pace with the broader adoption of Unicode email addresses. However, the effort was first raised eleven years ago to allow non-ASCII email addresses in WordPress
In the proposal, Gulbrandsen wrote that WordPress’s email sanitization is “based on US-ASCII characters and needs to be relaxed to allow for valid UTF-8,” while noting that the change could introduce challenges related to database compatibility, Unicode normalization, and existing code that assumes email addresses contain only ASCII characters.
Gulbrandsen proposed enabling WordPress to store Unicode email addresses for user accounts by extending functions such as is_email(), sanitize_email(), and antispambot() to support non-ASCII addresses. He noted that while PHPMailer updates included in WordPress 6.9 made it possible to send emails to Unicode addresses, but with a limitation, “ PHPMailer updates in WordPress 6.9 already made it possible for WordPress to send to Unicode addresses, but it’s not possible for users to use or store them on their account.”
Gulbrandsen said work on the issue was advanced during a contributor challenge sponsored by geoTLD.group and ICANN at WordCamp Vienna in April. Back then, Gulbrandsen, along with Alex Kirk, Benedikt Ledl, and Dennis Snell collaborated on a proposed WP_Email_Address class capable of parsing email addresses and returning decoded local and domain parts.
He wrote that the proposed WP_Email_Address class would be used by a filter to replace the decisions from is_email() and sanitize_email() with the new functions wp_is_unicode_email() and wp_sanitize_unicode_email().
Describing the benefits of the approach, Gulbrandsen said, “ This approach provides a path for interoperability with modern standards while preserving the ability to maintain the legacy behaviors, and it provides a helpful new class for structurally working with email addresses in various forms and places.”
Initial support merged for testing
The initial support for Unicode email addresses has been merged and is now available for testing. According to the announcement, is_email() and sanitize_email() can now accept non-ASCII email addresses on sites using utf8mb4 databases. He added that the enhancement can be disabled by removing the is_email and sanitize_email filters for wp_is_unicode_email() and wp_sanitize_unicode_email(), respectively.
The update also highlighted the new WP_Email_Address class that was introduced in the proposal. Snell highlighted that the changes make it possible to create WordPress accounts using email addresses that were previously not allowed, “It should be possible, therefore, to create WordPress accounts with email addresses not previously allowed. In addition, email validation is updated to match the WHATWG email specification so that WordPress and an <input type=email> element will agree on what is and what isn’t allowable.”
Snell also clarified that Unicode email support encompasses both internationalized domain names and email mailbox names, noting that while WordPress has supported Unicode domains through Punycode encoding for many years, it now accepts valid UTF-8 local parts that were previously rejected.
He warned that plugins and themes whose code assumes email addresses contain only ASCII characters may require updates to support the new functionality. He recommended using the new WP_Email_Address::from_string() method when working with email address data and urged developers to verify that any third-party services connected to their plugins properly support Unicode email addresses, noting that the feature can be disabled if compatibility issues arise.