Update & Notification Control with AdminEase: Tame the Email Avalanche

What you'll have when you finish

A WordPress install where auto-updates behave the way your deployment workflow expects (not "however WordPress shipped it"), where the dozen different categories of notification emails are individually toggleable, where the recovery-mode email goes to the address that can actually act on it, and where the dashboard is free of plugin upsell banners and "rate us five stars" nags. Configured once per site, replicable across a whole client fleet.

Prerequisites: A basic AdminEase install. No code required.
You'll need access to: a WordPress admin account, and a clear idea of your update strategy (do plugins update automatically, on a schedule, or only when you click).
Time: 10 to 15 minutes per site. If you manage many sites, AdminEase Pro's Import/Export feature lets you replicate this configuration across them.

This is the most agency-relevant article in the series A single WordPress site sends a manageable trickle of notification emails. Twenty sites send a flood. An agency that manages a hundred sites can easily generate four-figure email volumes per week from WordPress's default notification behavior. The toggles in this tutorial are individually trivial but compound into a meaningful inbox-management win when applied at scale.

The walkthrough

The agency problem and why these toggles exist
Auto-update controls: core, plugins, themes, translations
Update notification emails: the four "your site updated itself" emails
User account emails: new user notifications and password change alerts
Comment notification emails: author and moderator
Recovery mode: disable, or redirect to the right address
Silence the admin notice nag bar

1. The agency problem and why these toggles exist

WordPress's notification system was designed in an era when one person ran one site and wanted to know about everything that happened on it. Every comment that landed in moderation generated an email. Every new user generated an email. Every password change generated an email. Every auto-update generated an email. Every recovery-mode trigger generated an email.

For an individual blogger, that volume is informative. For an agency owner managing twenty client sites, it is unmanageable. The fix is not to filter the inbox after the fact, it is to disable the categories of emails that are not actually useful, and to redirect the ones that are useful to the right recipient. AdminEase exposes every notification source as an individual toggle, so the cleanup is granular rather than all-or-nothing.

All the toggles in this article live under AdminEase › Updates & Notifications, split into two subsections: Updates (the four auto-update controls) and Notifications (the ten email and admin-notice controls).

2. Auto-update controls: core, plugins, themes, translations

WordPress 5.5 added automatic background updates for plugins and themes, on top of the existing automatic core updates. By default, every site decides for itself whether to apply each category, and the result is inconsistent across a fleet. AdminEase exposes four independent toggles so you can pick exactly which categories should update themselves.

Configure them: AdminEase › Updates & Notifications › Updates. Four toggles: disable auto-update core, disable auto-update plugin, disable auto-update theme, disable auto-update translation. Set each to match your deployment strategy. Save.

What each toggle actually does at the code level:

Disable auto-update core filters auto_update_core, allow_major_auto_core_updates, allow_minor_auto_core_updates, allow_dev_auto_core_updates, and automatic_updater_disabled to return false at priority 9999 (high enough to win against other plugins that might try to enable updates).
Disable auto-update plugin filters auto_update_plugin and plugins_auto_update_enabled.
Disable auto-update theme filters auto_update_theme and themes_auto_update_enabled.
Disable auto-update translation filters auto_update_translation.

Three common strategies, none of them universally right Strategy A (security-conservative): enable core minor and translation auto-updates, disable plugin and theme auto-updates. WordPress security patches apply themselves; plugins update under your supervision. Strategy B (managed-deploy): disable all four auto-updates. Nothing updates without you running a deploy. Standard for agency sites with version-controlled deployments. Strategy C (set-and-forget): enable everything. Standard for small business sites where the owner just wants the site to keep working without intervention. Pick a strategy per client based on their risk tolerance and your maintenance capacity.

3. Update notification emails: the four "your site updated itself" emails

Separate from whether updates apply automatically is whether you get an email about it when they do. WordPress sends three different update-notification emails: one when core auto-updates, one when plugins auto-update, and one when themes auto-update. On a site with auto-updates on, that is three potential weekly emails. Across twenty sites, sixty.

Configure them: AdminEase › Updates & Notifications › Notifications. Three toggles: disable auto-core-update send email, disable auto-plugin-update send email, disable auto-theme-update send email. Save.

Each toggle filters the corresponding WordPress hook to return false: auto_core_update_send_email, auto_plugin_update_send_email, auto_theme_update_send_email. The updates still happen (or do not), exactly as configured in the previous section. The email about them simply does not get sent.

Centralize the visibility somewhere else If you turn off the update emails, you give up the easy "I see in my inbox what auto-updated last night" visibility. Replace it with a monitoring tool that polls update status across your fleet (ManageWP, MainWP, InfiniteWP, or a simple WP-CLI cron). The point is not to be blind to updates, it is to consolidate visibility into one place instead of having it scattered across an email-per-site-per-event.

4. User account emails: new user notifications and password change alerts

Two email categories trigger when users do user things, and both are toggleable.

New user admin notification. When someone registers a new account on your site, WordPress emails the admin to say so. On a public site with open registration, this can amount to dozens of emails per day. AdminEase's toggle filters wp_send_new_user_notification_to_admin (WordPress 6.1 and later) and wp_new_user_notification_email_admin (older fallback) to return false.

Configure it: AdminEase › Updates & Notifications › Notifications › Disable new user admin notification email. Save.

User password change admin notification. When a user changes their password or email address, WordPress emails the admin about it. On a site with many active users, the volume becomes irrelevant noise. AdminEase's toggle filters both send_password_change_email and send_email_change_email to return false, and additionally redefines the wp_password_change_notification() function as a no-op to cover an edge case in some plugins that call it directly.

Configure it: AdminEase › Updates & Notifications › Notifications › Disable user password change admin notification email. Save.

Don't disable both blindly on every site On a one-admin, low-user-volume site (a small business website with two editors), these notifications are useful early warning of suspicious activity. On a high-user-volume site (a membership site, an LMS, an active community), they are pure noise. Decide per-site. The default of "send everything to the admin" is correct on the first kind of site and wrong on the second.

5. Comment notification emails: author and moderator

Two different emails fire when comments interact with WordPress:

Moderator notification emails the site admin when a comment is held for moderation. AdminEase filters notify_moderator to return false.

Post author notification emails the post's author when a comment is left on their post. AdminEase filters notify_post_author to return false.

Configure them: AdminEase › Updates & Notifications › Notifications. Two toggles: disable comment admin notification email, disable comment post-author notification email. Save.

If comments are off, this does not matter If you already disabled comments via the Hardening tutorial (or via the dedicated Disable Comments feature in AdminEase), these toggles have no effect because no comments are coming in to notify about. Disabling them is harmless but unnecessary. Keep them in mind for sites where comments are active but the volume is high enough to be noise.

6. Recovery mode: disable, or redirect to the right address

WordPress 5.2 added recovery mode: when a fatal PHP error occurs in a plugin or theme, WordPress emails the site admin with a special URL that lets them log in and disable the offending code without bricking the site. The mechanism is genuinely useful. The default routing is not, because the admin email might be a generic admin@client-site.com address that nobody reads, or worse, the agency owner's personal inbox.

AdminEase offers two related controls for recovery mode.

Option 1 (disable entirely): AdminEase › Updates & Notifications › Notifications › Disable recovery mode email notification. Toggle on. Save.

This filters recovery_mode_email to return false, which suppresses the email entirely. Useful when you have external monitoring (Pingdom, UptimeRobot, your own status page) that catches site failures faster and more reliably than the recovery email anyway.

Option 2 (redirect to a specific address): AdminEase › Updates & Notifications › Notifications › Customize recovery mode recipient email. Toggle on. A child text field appears. Enter the email address (or a comma-separated list) that should receive recovery-mode emails. Save.

This adds a callback to recovery_mode_email that overrides the recipient before the email is sent. The input is sanitized through sanitize_email() for each address. The most useful destination for agencies is a shared support inbox or a notification routing service (PagerDuty, Opsgenie, a Slack-via-email integration) rather than an individual person's inbox.

Don't disable both Disabling the recovery email and not having external monitoring is a recipe for clients telling you their site is down before you know yourself. If you turn off recovery emails, make sure something else is watching for site failures. The "disable" and "customize recipient" toggles are alternatives, not toggles you should both leave off.

7. Silence the admin notice nag bar

The single most-requested feature in agency WordPress work, hidden as the last toggle in the article. The WordPress admin's "notices area" at the top of every screen is supposed to convey important information. In practice, it conveys plugin upsells, "rate us five stars" begging, free trial reminders, holiday sale banners, deprecated-plugin warnings, and the occasional actually-important security alert buried among them all.

AdminEase's Disable Admin Notices toggle removes every callback registered to admin_notices, all_admin_notices, network_admin_notices, and user_admin_notices via remove_all_actions(), hooked from admin_print_scripts so it runs after all plugins have registered their notices but before the admin renders them.

Enable it: AdminEase › Updates & Notifications › Notifications › Disable admin notices. Save. Open any admin page in an incognito window or after a hard refresh. The notices area should be empty.

This silences important notices too The toggle is intentionally nuclear: it removes every registered notice, including the ones that genuinely matter (a plugin telling you it needs configuration to work, a security plugin warning about a real vulnerability, a license-expired notice from a Pro plugin). The trade-off is the right one on a client-managed site where the agency handles maintenance separately, and the wrong one on a self-managed site where the owner relies on those notices. If you need finer control, the adminease_suppress_admin_notices filter lets you keep or restore specific notices from code.

Where to go from here

Fourteen toggles, two subsections, one underlying goal: replace WordPress's "send everything to one person" default with a configuration that matches how you actually manage sites in 2026. The single most agency-relevant change is the recovery-mode recipient redirect, because it solves the "client's admin email is dead and recovery mode is useless" problem that affects every long-running agency relationship. The single most fleet-relevant change is disabling the three update notification emails on every site at once, because it removes the largest single category of email volume from your inbox.

If you manage many sites, the next thing to look at is AdminEase Pro's Import/Export feature, which lets you replicate a known-good AdminEase configuration (including all the toggles in this tutorial) across a whole fleet rather than configuring each site by hand. The other tutorials in the series cover the related security, performance, and editorial-workflow surface area.

Frequently asked questions

If I disable auto-updates, how do I keep sites updated?

Either manually (log into the admin, click Update), or via a centralized management tool that runs the updates on a schedule under your supervision (ManageWP, MainWP, InfiniteWP, or a custom WP-CLI cron). The choice depends on your risk tolerance and fleet size. Manual works for a handful of sites. Centralized management is essential past a dozen.

Will the recovery-mode redirect work if my email server is down?

No. Recovery-mode emails go through WordPress's wp_mail(), which uses your configured SMTP or PHP mail setup. If that delivery path is broken (which is exactly the kind of failure recovery mode is designed to alert you about), the redirect cannot help. For high-availability monitoring, pair recovery-mode emails with an external uptime monitor that checks the site from outside the affected infrastructure.

What if a plugin's most important notice is now hidden?

The adminease_suppress_admin_notices filter, applied at the global level when the disable-admin-notices toggle is on, returns true by default but can be filtered to false from a mu-plugin. For finer control (suppress most notices but keep specific ones), you would need to hook earlier than AdminEase's removal action, capture and reattach the specific callbacks you want to keep, or maintain an allowlist in code. The toggle is intentionally simple; complex selective suppression is a developer task.

Does disabling new-user admin notifications affect users themselves?

No. The toggle only suppresses the email sent to the admin when a new user registers. The email sent to the new user (with their login credentials and welcome message) is unaffected. Same for password change: the user still gets their "your password was changed" confirmation; the admin just stops getting the copy.

Can I configure these settings differently for different user roles?

Not from the AdminEase UI. The toggles are global per-site. If you need per-role notification behavior (admins get update notifications but editors do not), that is a custom-code task: hook the relevant filter and check the user role before returning true or false. AdminEase's toggles are global on/off switches by design.

How do I replicate this configuration across a fleet of sites?

AdminEase Pro includes an Import/Export feature that serializes the full AdminEase settings to a JSON file. Configure one site as a template, export the settings, then import them on each additional site. For very large fleets, scripting the import via WP-CLI is the next step up. There is no built-in "push this configuration to all my sites at once" feature in AdminEase itself; that role is filled by external multi-site management tools.

Was this article helpful?