Allow author email addresses to stay private

[WPprodigy]

Summary

Improve user privacy by hiding email addresses by default in the notifications subscriber list and editorial comments.

Problem: Any user with post editing access could discover email addresses of all users who can publish posts via the notifications panel. As noted in the original discussion: "If Beyoncé contributed to my site, everyone who is a contributor or higher can find her email."

Solution:

• Show user_nicename instead of email in notifications list (provides unique identification without exposing email)
• Remove mailto: link from editorial comment author names
• Add filters to customise behaviour or restore emails if needed

Changes

• Notifications list: Now shows user_nicename (e.g., john-smith) below the display name instead of email
• Editorial comments: Author name is now plain text instead of a mailto: link
• New filter ef_user_secondary_identifier: Customise what's shown below the display name
• New filter ef_editorial_comment_show_email_link: Restore mailto: links in comments

Restoring previous behaviour

// Show email in notifications list
add_filter( 'ef_user_secondary_identifier', function( $identifier, $user ) {
    return $user->user_email;
}, 10, 2 );

// Show email links in editorial comments  
add_filter( 'ef_editorial_comment_show_email_link', '__return_true' );

Test plan

• PHP integration tests added (3 tests)
• View notifications metabox on a post - should show nicename, not email
• View editorial comments - author should not be a mailto: link
• Verify filters work to restore previous behaviour

Fixes #264

---

This is a fresh reimplementation based on the discussion in PR #577. The original PR was 5 years old and needed rebasing. This implementation follows the consensus from @cojennin and @jerclarke to hide emails by default and show an alternative unique identifier.

🤖 Generated with Claude Code

[cojennin]

Removing the email makes sense but I'd like to substitute the user role in it's place (which would be more helpful anyway). Let's remove the email and substitute it for the role in this PR, then it's good to merge.

[cojennin]

Let's add a filter for this value on the user list as well, in case folks want to substitute for some alternative (like username).

[WPprodigy]

Removing the email makes sense but I'd like to substitute the user role in it's place (which would be more helpful anyway). Let's remove the email and substitute it for the role in this PR, then it's good to merge.

To confirm, you're thinking the default behavior should be no email displayed but usernames instead?

If so, I'm definitely not opposed - but do need to note that there is a "feature" removed, in that clicking on a commenters name currently opens up a mailto link to directly email them. Doesn't seem all the needed IMO, but I would need to defer to those using these in real editorial flows.

Secondly, it could look a bit funny if the user has chosen their display name to be the username. That's fixable though.

Let's add a filter for this value on the user list as well, in case folks want to substitute for some alternative (like username).

I'd like to avoid more filters/actions in regards to the markup output. Integrating with the block editor in the future will probably mean a new UI, utilizing Gutenberg styles/components. Keeping compatibility with PHP-level custom markup will be tricky at that point, so ideally we keep things as light as possible moving forward.

[cojennin]

To confirm, you're thinking the default behavior should be no email displayed but usernames instead?

I was only thinking of the notifications panel. Swap the email with username or role (or both) to help with identification and make it filterable

If so, I'm definitely not opposed - but do need to note that there is a "feature" removed, in that clicking on a commenters name currently opens up a mailto link to directly email them.

Keep it filterable for comments, don't remove it. If you're commenting on a post it's because you've got access to it. As opposed to the notifications panel, where you can find folks emails regardless of whether you should have access to them.

If Beyoncé contributed to my site, everyone who is a contributor or higher can find her email by creating a post and looking her up in the notifications panel. The only folks who could find her email through the editorial metadata are editors or higher, and only if she comments on the post. Editorial metadata needs rethinking, but the notifications panel is more problematic.

[WPprodigy]

Keep it filterable for comments, don't remove it. If you're commenting on a post it's because you've got access to it. As opposed to the notifications panel, where you can find folks emails regardless of whether you should have access to them.

True, though I think for the case in #264 the commenters don't necessarily want their email public either.

I see what you're thinking now. Makes sense. I'll try out some variations of username / role and see what will make a good default.

If Beyoncé contributed to my site

One can only hope 😆.

[WPprodigy]

Hmm, so the more I look into this, the more it seems we should just leave it empty underneath the user's display name.

• user_login: Could be sensitive / contain email address still - user@example.com
• user_nicename: If the above was an email, then this would just be userexample-com, still not good.
• ID: Not terribly useful.
• Role: Users can have more than one role. Picking just the first and displaying it could be misleading.

Whereas the display_name, what we are currently displaying, is a customizable value that the user has control over. Defaulting to the First + Last name.

I'm definitely leaning towards "less is more" here. If we start with leaving it empty, we can see what happens. If no reports come in, then all is good. If there is a future report requesting more specific identifiers be shown, then we could act on that.

[cojennin]

Using just display_name makes it both more difficult to determine "at a glance" who's receiving the notification, and also creates situations where it would be impossible to determine who's receiving a notification (with folks who share first/last names).

Email is the most useful information to show (as a unique identifier to help make "at a glance" and definitive determinations) but problematic from a privacy standpoint (see: Beyoncé). However, positively and absolutely identifying a user will be even more important for cases like #273

The concerns around user_login/user_nicename are legit, but it seems like the next best to use if we want to eliminate email. We can add an apply_filter to the user_login/user_nicename (for folks who may want to bring back email or substitute some alternative identifying information).

[jerclarke]

Sorry I never replied, lol. FWIW I'd be fine with just names, though showing user_nicename would be apprciated as it would always be unique and help you differentiate two seemingly-identical accounts.

[GaryJones]

Implementation Summary

This PR was reimplemented from scratch after 5 years, incorporating the feedback from the original discussion. Here's what we landed on:

What changed

1. Notifications list: Now shows user_nicename instead of email address
2. Editorial comments: Author name is plain text instead of a mailto: link
3. Filters added for sites that need the old behaviour

Why these decisions

Why user_nicename instead of email?

• Provides unique identification (addresses @cojennin's concern about differentiating users with the same display name)
• Doesn't expose private information (the Beyoncé scenario)
• Unlike user_login, it's sanitised and won't accidentally contain an email address
• As @jerclarke noted, it helps differentiate "two seemingly-identical accounts"

Why hide email by default?

• Privacy-first approach aligns with how WordPress core treats emails (never exposed except for admins or own account)
• The original issue Privacy/Security: Need ability to hide user emails in Notifications metabox #264 specifically requested this for privacy reasons
• Sites that need emails can easily restore them via filter

Why filters instead of removing email entirely?

• Some editorial workflows genuinely benefit from quick email access
• Filters provide flexibility without breaking existing workflows
• Follows WordPress patterns of sensible defaults with customisation options

Restoring previous behaviour

// Show email in notifications list
add_filter( 'ef_user_secondary_identifier', function( $identifier, $user ) {
    return $user->user_email;
}, 10, 2 );

// Show email links in editorial comments  
add_filter( 'ef_editorial_comment_show_email_link', '__return_true' );

Thanks to @WPprodigy for the original implementation work and to @cojennin and @jerclarke for the thoughtful discussion that shaped this solution.

[jerclarke]

RIGHT ON! Love to see this, thanks Gary!