20 Comments

  1. David McCan
    · Reply

    Hmm. This doesn’t seem like it adheres to the 80/20 rule. I don’t think 80% of sites need the admin email verified twice a year.

    Report

    • Otto
      · Reply

      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.

      Report

      • Lee

        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.

        Report

      • David McCan

        Wow, 90% of WordPress sites have an outdated or non-working admin email address. That is a surprising level.

        Report

      • Peter Shaw

        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?

        Report

      • James Mailen

        @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?

        Report

    • Kingsley Felix
      · Reply

      You think 80/20 rule works? if it does Gutenbug won’t be in CORE

      Report

  2. SVETOSLAV MARINOV
    · Reply

    if the person is locked out they can just use SAK4WP (Swiss Army Knife for WordPress) to get back in. Full disclosure: it’s one of my tools

    Report

  3. Lawrence
    · Reply

    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.

    Report

  4. Miroslav Glavic
    · Reply

    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.

    Report

  5. Jonathan Perlman
    · Reply

    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?

    Report

  6. DJ Steve B
    · Reply

    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.

    Report

  7. fwolf
    · Reply

    TL;DR? The essence of all comments is: Hooray for Feature Creep!
    Don’t do this, its going to add even more mail clutter .. but would Automattic after Gutenborg even care? I don’t think so.

    cu, w0lf.

    Report

  8. Steve
    · Reply

    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”.

    Report

  9. John Rood
    · Reply

    More bloat. No need for this in the core.

    Report

  10. Robi Erwin Setiawan
    · Reply

    I think better than 2FA in core. It will make wordpress stronger.

    Report

  11. Nathan Lyle
    · Reply

    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.?

    Report

  12. Georg Schmidt
    · Reply

    Completely useless feature. Please fix the bugs in Gutenberg instead, it is still not useable on a serious level besides some “single user photo holiday blog”. Thank you.

    Report

  13. Martin
    · Reply

    add_filter('admin_email_check_interval', '__return_false');

    You’re welcome. This will go into any theme I make/maintain. Very good points in the comments already. No need to repeat them.

    Report

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: