WordPress auto-updates shipped as opt-in for plugins in 5.5, then flipped to opt-out for most managed hosts by 2025. The feature works—until you run a staging environment.
The problem: auto-update preferences are stored in the database, not in code. When you enable auto-updates for a plugin on production, then clone your site to staging for testing, staging inherits that same setting. If staging pulls an update first and you later sync the database back to production, you’ve just pushed untested code live without realizing it.
Most operators discover this after a layout breaks or a payment form stops submitting. The fix isn’t intuitive, because the WordPress dashboard shows auto-updates as a per-plugin toggle with no environment awareness.
Where auto-update state lives
Plugin auto-update preferences are stored in the wp_options table under the key auto_update_plugins. It’s a serialized array of plugin basenames. When you enable auto-updates for a plugin, WordPress adds its basename (e.g., akismet/akismet.php) to that array. When you clone a database, you clone that array.
Managed hosts like WP Engine, Kinsta, and BigScoots run their own update schedules—usually twice daily. If your staging site is on the same host infrastructure and shares the same cron timing, it can pull updates before production does. The update itself isn’t the issue; it’s the accidental database sync afterward that surfaces the problem.
This is distinct from WordPress core auto-updates, which are controlled by the AUTOMATIC_UPDATER_DISABLED and WP_AUTO_UPDATE_CORE constants. Those live in wp-config.php and can be set per environment. Plugin auto-updates don’t have an equivalent constant—yet.
The config-level override
You can disable plugin auto-updates entirely on staging using a filter in your theme’s functions.php or a custom plugin. Add this to your staging environment only:
add_filter( 'auto_update_plugin', '__return_false' );
This filter runs before WordPress checks the auto_update_plugins option, so it overrides any database settings. Your staging site will never auto-update plugins, even if the dashboard toggle is on. Production can still auto-update as configured.
If you want more control—say, allow auto-updates for specific plugins on staging but block others—you can inspect the $update object passed to the filter:
add_filter( 'auto_update_plugin', function( $update, $item ) {
$allowed = [ 'akismet/akismet.php', 'hello-dolly/hello.php' ];
return in_array( $item->plugin, $allowed );
}, 10, 2 );
This approach whitelists only the plugins you name. Everything else stays manual.
The deployment risk most operators miss
The inverse scenario is equally common: you disable auto-updates on production because you want full control, then push your database to staging for testing. Staging now also has auto-updates disabled—but you wanted staging to pull updates automatically so you could test them before manually applying to production.
The cleanest fix is to treat auto-update state as environment-specific config, not content. That means:
- Set the filter in code, per environment
- Ignore the dashboard toggle, or document that it’s overridden
- Never sync the
auto_update_pluginsoption between environments
If you’re using a database sync tool like WP Migrate or All-in-One WP Migration, add auto_update_plugins to your exclusion list. Most tools let you skip specific option keys during import.
When auto-updates make sense
For solo operators running a single production site with no staging, auto-updates work well for low-risk plugins: Akismet, Yoast SEO, contact forms. The risk is low because you’re already trusting the plugin author’s release process, and critical security patches ship faster than you’d apply them manually.
For sites with custom plugins, membership logic, or payment processing, the calculus flips. An auto-update that changes a filter priority or deprecates a function can break checkout flows without warning. Staging exists to catch that—but only if staging doesn’t push updates back to production through an accidental database sync.
The non-obvious tip: if you run multiple staging environments (e.g., one for content review, one for plugin testing), disable auto-updates on the content-review staging and enable them on the plugin-test staging. That way your content team never sees surprise layout changes, and your dev environment always has the latest code to test against.
Want more WordPress operations breakdowns? Reply with the hosting or plugin behavior you want explained next—we cover one every Monday.