Open the Plugins screen on any WordPress site that is a few weeks behind. Under each outdated plugin, WordPress injects an amber row: "There is a new version of WooCommerce available. View version 10.9.4 details or update now." The Plugins menu item picks up a count badge. On a site with thirty plugins the table stops being scannable.
Most guides hand you one line and stop. The line usually looks like this:
add_filter('site_transient_update_plugins', '__return_null'); // please don't
That does not hide the notice. It empties the transient WordPress stores update results in, so core stops knowing that any plugin has an update. The rows disappear as a side effect, because there is nothing to render. You have not cleaned a dashboard, you have blinded the site, and the next developer to inherit it finds a quiet admin sitting on top of a year of unapplied security releases. If you find that filter in a client site, take it out.
Here is the actual thing that prints the rows. wp_plugin_update_rows() is hooked to admin_init at priority 20, and it loops the update_plugins transient adding a wp_plugin_update_row callback to after_plugin_row_{$file} for every outdated plugin. So you unhook the parent, from an earlier priority on the same hook:
add_action('admin_init', function () {
remove_action('admin_init', 'wp_plugin_update_rows', 20);
}, 1);
The rows are gone. The update check still runs, which is the point. Load the Plugins screen and the count badge is still on the menu item.
That badge never came from the notice. It is built by wp_get_update_data(), which counts pending core, plugin, theme and translation updates and feeds both the admin menu bubble and the toolbar. So it needs a second hook:
add_filter('wp_get_update_data', function ($data) {
$data['counts']['plugins'] = 0;
$data['counts']['total'] = 0;
$data['title'] = '';
return $data;
});
Now the rows and the badge are both gone and the update check is intact. Then you want the same treatment for theme update notices, and core, and each one has its own removal. By the time you have covered them all you have a mu-plugin, and the mu-plugin has to travel to every site you build. Miss a hook on one and that client gets a half cleaned dashboard.
I tested the settings-panel version with WP Adminify Pro instead. 20 second demo below.
What plugin update notices actually cost on a client site:
- One amber row per outdated plugin, plus a count badge, for every admin who logs in
- The notice is aimed at whoever does the updates, which on agency builds is not the person reading it
- Clients either learn to ignore amber warnings, or they run an update on production unsupervised
- The rows cannot be dismissed, so they never clear until someone updates
What changed after enabling Hide Admin Notices in Adminify Pro:
- One toggle under Productivity covers the plugin update rows for every plugin at once
- The Plugins count badge clears with them, no separate
wp_get_update_datafilter to remember - The same module handles the rest of the notice pile-up, so the admin opens to work rather than a stack of banners
- The update check keeps running, so a maintenance report still sees every pending update
- Survives WordPress updates, no snippet to carry between sites
The caveat I will not skip: hiding the notice does not update the plugin. Your versions are unchanged and any security release you are behind on is still unapplied. This is right when the update has an owner and a schedule: you, your agency, a managed host, an automation with rollback. It is wrong on a site nobody maintains, where the amber row is the only signal anyone will ever get. Decide who owns updates first. Then hide the notice. And whatever you decide, do not null the transient.
Step-by-step doc: https://wpadminify.com/docs/adminify/productivity/hide-admin-notices
How do you handle plugin update notices on sites you maintain for other people: unhook wp_plugin_update_rows, hide them with a plugin, or leave them visible on purpose?
Top comments (0)