WordPress 5.3 to Introduce New Admin Email Verification Screen

WordPress 5.3 is set to introduce an admin email verification screen that will be shown every six months after an admin has logged in. The feature was proposed seven months ago in a ticket that contributor Andrei Draganescu opened as part of the Site Health component improvements.

Draganescu said the idea came from discussions in the #core-php channel regarding WSOD (White Screen of Death) recovery emails, which are sent when a site experiences a fatal error and the administrator may be locked out of their WordPress site. Participants in the discussion raised the issue of how common it is for admin email addresses to be outdated or set to a “catch all” address that is never checked. The email address may also be set automatically by the host during the process of a one-click installation.

The “Why is this important?” link leads to a WordPress support article that describes the various uses for the admin email address, such as new user registration notifications, comment approval, and maintenance messages.

Although it wasn’t the stated intention for the new admin email verification screen, the feature could become important for improving communication prior to automatic updates. Requiring admins to verify their email addresses after six months could ensure that more addresses are kept current, especially for admins who check their sites infrequently.

When the WordPress security team proposed auto-updating older versions of WordPress to 4.7, one of the chief concerns is whether WordPress will be able to reach admins whose emails have been abandoned. This new admin email verification screen will not be be useful for older WordPress sites, but in the future, when auto-updating for major versions becomes the standard, it will help ensure more administrators are getting those notices to a working address.

A new admin_email_check_interval filter is available for developers to customize the interval for redirecting the user to the admin email confirmation screen. Those who find it to be unnecessary or annoying can set a very large interval for the check.

22

22 responses to “WordPress 5.3 to Introduce New Admin Email Verification Screen”

    • It’s probably more like 90% that do.

      The bottom line is that the outdated or non-working addresses is really a security problem that needs to be fixed. If sites are being used and breaking because people aren’t maintaining them properly, then they need to be told about it and forced to step up to the task.

      • More like we need two separate email addresses recorded in each site’s settings: 1, an general/admin email address, and 2, an alerts email address.

        The admin email is used by plugins for mixed purposes such as a) to send alerts to the site admin, and b) as the default address for contact forms. Many developers set the site admin address to their own email address instead of the site admin’s/owner’s email address because site owners/admins have a natural hate of what they regard as spam, inclusive of the ‘Your site has been updated to…’ emails sent by WordPress. We need an option to set an alerts email address and a general purpose/admin email address.

      • Otto,

        Your stats are rubbish.

        If the admin address is defunct and they have forgotten their password the site has been abandoned. This won’t solve that and just adds useless code and creates an annoying experience.

        How about for every feature added to core we move something to a plugin?

      • @Otto

        Why?

        I’m not trying to be snarky, I legitimately want to know why you think people should be forced to do this. Other than “security is important”, that’s a bit too broad and I’m not convinced this really improves security. Maybe it does, but someone needs to convince me.

        We all know “security is important”, but it seems to be tossed around like a “think of the children!” phrase. You feel people need to be forced to validate their admin email…but these are the same people who likely don’t care and I would wager a majority don’t log in anyway. In these cases it’s wasted effort and for the rest of us it’s a pain (well, some of us will write or install a PlugIn to stretch out the time to decades and it’ll be a minor inconvenience).

        I work on hundreds of sites, for each one I have a local install and a staging site (I code locally and upload to staging for review). So two thirds of the sites I work on aren’t “real” websites and a third aren’t accessible on the web. I generally don’t setup my local installs with an outbound mail server.

        Have use cases like this been considered and if so then how would you handle this situation?

  1. I read a post on Morten Rand-Hendricksen’s site about the 80/20 rule. Summary is that it isn’t really adhered to anymore, but for some reason WordPress still notes it as a guiding principle.

    Partly, he states that often there is no data to even know if a feature is used. I find that somewhat interesting, and wonder if we shouldn’t be using data to make better informed decisions about the codebase (versus letting random core contributors guide/push for their pet ideas).

    There may be some debate on new things like Gutenberg since, of course, a new thing is always resisted and, also of course, a new thing will have an adoption period, and also even more of course, there are some who will raise the rebel flag and yell “never!” and attempt to drive a wedge to hold onto classic ideologies. I’m not saying that is bad or good; just that it is expected.

    However, then we come across work/effort on things like this. Who says this is a problem? Where is the data? I’m sure it has *been* a problem for many sites, but what percentage of sites? 1%? 10%? 30%? I doubt the very people who wrote this code have any real data.

    This is a ripe idea for a security plugin for those who feel that their websites (or their clients’ websites) need this because it is, or potentially could be, an issue there. (I won’t even go into whether I think this ‘check’ will actually solve anything).

    Are not the big vendors in the security plugin world already adding this ‘feature’? If not, why? Why is this now more (bloated) code in core?

    I’ll have to look at the code, but questions also arise as to its implementation. I know no one cares about performance anymore and we (collectively as web developers) seem to think its a niche hobby. Talk all you want about carbon output and global warming. Every piece of code causes it. Thus, I think the 80/20 rule is a decent guide here. How often is this six-month check being performed? Is this being done via wp-cron? Daily? Hourly? Sigh… you get my point.

    Lastly, the whole 80/20 thing sort of grates me. We *still* have a call to Windows Live Writer loading on WordPress. Microsoft themselves, the creator of WLW, abandoned it in 2012, and officially declared it dead in 2017. If it was ever used by more than 10% of WordPress users, I’d be shocked, but most WP devs don’t even know what it is anymore at this point. Some discussions over in core a few years back where had about removing it, but they seemed to have died. So, it lives on, maybe for another five years.

    Clearly, it should have long ago been slung off to its own plugin. In fact, I don’t even think it’s WordPress’s role to make it a plugin, just to kill it in the core.

    So, think about this. We now have ‘niche’ performance/optimization experts who, among many other ‘adjustments’ insert code into child theme functions.php or snippet plugins or their own custom plugin, to remove/undo support for WLW.

    Of course, that code *also* has to execute (more CPU cycles) so while it’s a major improvement (since it’s server-side only at the speed of (hopefully) PHP 7.3, it’s still a band-aid on the real issue: WordPress’s fear of letting legacy code die.

    My personal feeling is that the WordPress codebase could be about 10-15% leaner and not affect 99% of its current users.

    Adding this personal pet project of someone’s doesn’t help WordPress, really. It just becomes one more thing, one more hook, that developers have to deal with now. I know no one at WordPress is fearing SSGs, or even Drupal & Co., as they stand no chance of taking marketshare of WordPress. But does it need to be about fear? Can’t we just do what is sensible for our users?

    Start by cleaning up the core instead of adding to it. I was recently reminded about a not-so distant iOS update that was _mostly_ about tightening up the performance and cleaning up legacy code in the O/S. I think WordPress needs to dedicate an upcoming release (maybe 5.5?) to that end.

  2. There are better things for me to worry but…

    I use admin@ for the e-mail addresses of all my domains

    admin@ for the WordPress installation to do it’s thing, and the WordPress profile, I set up miroslav@ but never changed the profile e-mail addresses.

    For All In One WP Security ip ban/lockout e-mails, I use a specific @gmail.com address.

    So I am going to have to click a link twice a year for every WordPress installation? I have 45+ installations.

  3. So how does this work on multi-site in higher education? Are my 200 editors of 200 sites going to be forced to verify the email every six months? Am I as an admin going to have to verify 200 sites for them instead?

  4. Please. No.

    Doing this two hundred times a year will not make me check my catch all emails for notices. I get so many notices from the ‘shield plugin’ that I think two of my server setups are getting emailed throttled, and I no longer look at a single email sent by any wp system.
    This would just add to the pile of email that is never read, clogging up the systems like contact form 7 spam mails.

    I love it when WP does minor updates and I get 200 emails saying yay your site just updated – I don’t open them, it just stresses me out wondering if the update broke anything and if I am missing important email in the deluge of wasted mailbox space these things take up.

    A useful thing would be some kind of emclient/thunderbid/outlook script that would auto-check and notice that WP admin only got 195 emails for site updates and that 200 were expected, so likely this cool update broke the 5 sites that did NOT email…

    The four times I tried to find an email about a site crash / whitescreen warning, only one email was received – and this is a self hosted catch all addy without spam filtering from google.. so the mails were not sent for some reason.

    What might be a reasonable thing to add – a notice for any author that logs in, showing,
    “hey, btw, the main notify / reset email is set as “youroldname@aol.com” –

    Would you like to change that? (if super admin)
    – like to add another email addy to get important site notices? (if admin abilities)

    So notices can be sent to an email box you check more often if something is needed.

    (I actually saw an old aol email as admin / contact form 7 notify on a client site last month)

    I can see the importance of this, and feel sorry for people who had WP setup for them by someone and don’t know about this setting…

    but If I have to click to verify an email for WP it will waste so much time, I’d rather find a plugin to remove this ‘core feature’ and install it 200 times than click an email notice that will likely add to the spam points on my servers.

    Like above Peter Shaw said “How about for every feature added to core we move something to a plugin?” – I’ve been saying this for years. Most new wp stuff could, should be a plugin, not a core thing that forces us to add plugins to remove.

  5. No thanks.

    I route hundreds of automated WordPress-related email notifications per month to an inbox I never check.

    They’re annoying and this is going to be even more annoying.

    Now I’ll have to install yet another plugin on every website to disable this “new feature”.

  6. I’m not a fan of this addition. I don’t think it’s clear enough what it is, given that there are different types of “admin” logins. My clients, for example, have that level but wouldn’t typically recognize this for what it is, and they either worry about what it means or try to change it because it’s not their email address. I get the idea of why, but I think it creates as much of a headache as it helps.

    Question – do only admin logins see this? Not subscribers, customers, etc.?

    • Same here. Seems nobody of core committers even try to test their changes in various environments.

      WordPress seem to be broken on so many levels nowadays, but nobody wants to admit this. The saying of “emperor new clothes” strikes again, too bad.

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.