You open Plugins in wp-admin and the Automatic updates column is gone. There are no “Enable auto-updates” links, and Screen Options only offers the Description column, so you cannot switch it back on from there.
This came up again on the WordPress.org support forums this week. The column is not broken. WordPress hides it on purpose when auto-updates are switched off somewhere, and the job is to find out where.
It hits single sites where a constant, a plugin or the host turned off the automatic updater, and multisite admins who are looking at the wrong screen.
How WordPress decides to show the column
The check lives in the WP_Plugins_List_Table constructor. This is the exact line from core:
$this->show_autoupdates = wp_is_auto_update_enabled_for_type( 'plugin' )
&& current_user_can( 'update_plugins' )
&& ( ! is_multisite() || $this->screen->in_admin( 'network' ) );All three conditions must be true. So the column disappears when:
- plugin auto-updates are disabled (a constant in wp-config.php, or a filter in a plugin or mu-plugin)
- your user cannot
update_plugins - you are on a multisite subsite instead of Network Admin
wp_is_auto_update_enabled_for_type() asks WP_Automatic_Updater::is_disabled() first. That method returns true when file changes are not allowed (DISALLOW_FILE_MODS), when AUTOMATIC_UPDATER_DISABLED is true, or when the automatic_updater_disabled filter says so. After that, the plugins_auto_update_enabled filter gets the final word.
That gives you a short list of constants and filters to hunt for. Start with the cheapest check.
Step 1. Ask WordPress what it thinks
If you have WP-CLI, run this from the site root:
wp eval 'var_dump( wp_is_auto_update_enabled_for_type( "plugin" ) );'You should see bool(true) or bool(false). If it is bool(true) and there is still no column, skip to Step 4 (permissions and multisite).
If it is bool(false), something disabled the updater. Keep going.
Step 2. Check wp-config.php for the constants
Back up wp-config.php before you touch it. Then search it:
grep -nE "AUTOMATIC_UPDATER_DISABLED|DISALLOW_FILE_MODS" wp-config.phpNo output means neither constant is in that file. If you get a line number, that line is your culprit (or one of them).
The official wp-config.php docs describe both. AUTOMATIC_UPDATER_DISABLED switches off every background update. DISALLOW_FILE_MODS goes further and blocks installing and updating plugins and themes from wp-admin, plus the file editor.
If you only wanted to stop automatic core updates, the constant you probably meant is WP_AUTO_UPDATE_CORE. It is not part of the check above, so it leaves the plugin column alone. Swap it in like this:
// define( 'AUTOMATIC_UPDATER_DISABLED', true );
// Stop automatic core updates, keep plugin/theme auto-update controls
define( 'WP_AUTO_UPDATE_CORE', false );
Reload the Plugins screen and the column should be back. Your earlier per-plugin choices live in the auto_update_plugins option, so they come back with it.
💡 If you find DISALLOW_FILE_MODS, ask why it is there before you remove it. Hosts and agencies set it on purpose to lock the file system, and removing it also brings back plugin installs for every admin.
Step 3. Find the plugin or mu-plugin that filters it off
No constant? Then a filter is doing it. Search the code that loads on every request:
grep -rnE "automatic_updater_disabled|plugins_auto_update_enabled|file_mod_allowed" \
wp-content/mu-plugins wp-content/plugins wp-content/themesA typical hit looks like add_filter( 'automatic_updater_disabled', '__return_true' );, or plugins_auto_update_enabled with __return_false. Update managers, security plugins and “disable updates” plugins all use these hooks. Ignore hits inside files that only check the value, and look for the add_filter() calls.
Check wp-content/mu-plugins first. Hosts like to drop their update control there, and mu-plugins do not show up in the normal plugin list or get deactivated with the rest.
No shell access? Do what the forum moderator suggested: deactivate plugins one by one (or all of them on a staging copy) and reload the Plugins screen after each.
Step 4. Rule out the user and multisite
If Step 1 printed bool(true), the updater is fine and the problem is who is looking:
- On multisite the column only shows in Network Admin > Plugins. A subsite admin never sees it, by design.
- A role without
update_pluginsgets no column either, for example an admin whose capabilities were trimmed by a role editor plugin. - Rarely, CSS from a theme or admin-styling plugin hides it. The moderator in the thread called that possible but unusual.
To check the capability for a specific account:
wp user list --role=administrator --fields=ID,user_login
wp eval 'var_dump( user_can( 1, "update_plugins" ) );'Replace 1 with the user ID from the first command. bool(false) means that account cannot update plugins, so the column stays hidden for it.
When the host is the one turning it off
In the forum thread, the site owner traced the missing column to the automatic update feature of Installatron in their hosting panel. Installer tools like Installatron and Softaculous can manage WordPress updates for you, and that can mean keeping WordPress’ own updater out of the way.
My advice: pick one updater, not both. If you want the host to handle updates, leave its setting on and accept that the column is gone.
If you want per-plugin control in wp-admin, turn off the host’s auto-update for that install first. Then remove whatever constant or mu-plugin it left behind (Steps 2 and 3). Do it in the other order and the host tool may simply put it back.
If your server runs OpenPanel, WP-CLI is preinstalled in every PHP container. You can run the commands above from Containers > Terminal by picking the PHP container and adding --path=/var/www/html/example.com --allow-root. On cPanel you would use SSH or the Terminal feature instead, if your host has it enabled.
Once the column is back, confirm the per-plugin status from the command line:
wp plugin auto-updates status --allYou get a table with each plugin marked enabled or disabled. This command needs WP-CLI 2.5 or newer.
For every constant that can change this kind of behavior, keep my list of all WordPress constants handy. If updates are failing rather than hidden, Another Update Is Currently in Progress and FS_METHOD explained cover the usual causes.
TL;DR: the Automatic updates column only shows when plugin auto-updates are enabled, your user can update_plugins, and you are not on a multisite subsite. Check wp-config.php for AUTOMATIC_UPDATER_DISABLED or DISALLOW_FILE_MODS, grep mu-plugins and plugins for the automatic_updater_disabled and plugins_auto_update_enabled filters, and switch off any host-level auto-update tool before you remove what it added. As of 2026-11-07, this is how the current core code decides it.
