How to selectively disable WordPress updates

WordPress updates do not have to be managed as an all-or-nothing decision.

You may want WordPress core security updates to continue normally while temporarily preventing one plugin from updating. You may want plugin auto-updates disabled on production while keeping update notifications visible. Or you may need to hold a theme release until it has passed staging tests without suppressing unrelated updates across the entire site.

WordPress provides several different mechanisms for controlling updates, and understanding the difference between them is important.

Disabling an automatic update is not necessarily the same as hiding an available update. Disabling plugin updates is not the same as disabling WordPress core updates. A global configuration constant is not equivalent to a per-plugin rule.

The safest approach is usually selective control.

Disable only the update behavior that has a documented reason to be paused, leave unrelated updates available, and review every exception regularly.

This makes selective update control useful for staging-first deployments, compatibility testing, managed client sites and temporary holds. Used carelessly, however, the same controls can leave vulnerable software frozen for months without anyone noticing.

What does selectively disabling WordPress updates mean?

Selectively disabling WordPress updates means preventing a specific category or component from updating automatically without shutting down the entire WordPress update system.

Depending on the requirement, you might want to control:

• WordPress core updates;
• plugin automatic updates;
• theme automatic updates;
• translation updates;
• one specific plugin;
• one specific theme;
• update notifications;
• background update execution.

These are separate behaviors.

A good implementation should therefore begin with a precise question:

What exactly do you want WordPress to stop doing?

Available updates and automatic updates are different

WordPress can detect that a new version exists without automatically installing it.

For example, a plugin can display an available update in Plugins → Installed Plugins while its automatic update setting remains disabled.

This is often a useful production configuration because administrators remain aware of new releases but can test them before deployment.

Manual updates can remain available

Disabling automatic updates for a plugin through WordPress’s normal per-plugin controls does not prevent an administrator from manually clicking the update action later.

This distinction is particularly useful in a staging-first workflow.

You can disable automatic deployment, test the update when convenient, and then apply the approved version manually.

How WordPress automatic updates work

WordPress includes a background update system that can handle several types of software.

The official WordPress upgrading documentation describes configurable automatic updates for:

• WordPress core;
• plugins;
• themes;
• translations.

These categories can be controlled differently.

Core updates

WordPress core automatic-update behavior depends on the installation, version and configuration.

The WP_AUTO_UPDATE_CORE constant can explicitly configure core behavior.

For example:

define( 'WP_AUTO_UPDATE_CORE', false );

This disables automatic WordPress core updates.

Alternatively:

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

limits automatic core updates to minor releases.

Setting it to true enables automatic development, minor and major core updates where applicable.

Plugin and theme auto-updates

WordPress has provided administrator-facing per-plugin and per-theme automatic update controls since WordPress 5.5.

The official plugin and theme auto-update documentation explains that administrators can enable or disable automatic updates individually.

For plugins, the control appears in the Plugins screen.

For themes, it is available through the theme details interface.

Translation updates

WordPress also manages translation files separately.

This matters because disabling plugin updates does not automatically mean translation updates should also stop.

An update policy should treat each update type independently when there is no reason to couple them.

Why would you disable an update selectively?

There are legitimate operational reasons to pause an update.

The important distinction is between a deliberate temporary exception and permanent neglect.

A compatibility issue was confirmed in staging

Suppose a new version of a plugin breaks checkout, a page builder integration or custom code during staging tests.

Deploying that release immediately to production would be irresponsible.

Temporarily holding that plugin while allowing unrelated plugins to continue updating can be a sensible response.

A critical plugin requires a controlled deployment window

Some components deserve more testing because their failure would have significant business impact.

Examples include:

• payment gateways;
• membership systems;
• authentication plugins;
• multilingual plugins;
• complex page builders;
• form systems tied to CRM workflows;
• plugins performing database migrations.

A production site may keep their automatic updates disabled while testing each new release through a controlled workflow.

See Building a Staging-First WordPress Update Workflow for that process.

A site uses custom code that depends on a specific version

A temporary version hold may be justified while custom integrations are updated.

However, depending indefinitely on an obsolete plugin version is technical debt, not a durable compatibility solution.

Updates are managed externally

Some managed hosting providers, deployment systems or agency workflows manage WordPress updates outside the standard dashboard process.

In those environments, WordPress’s own automatic-update behavior may be intentionally restricted to avoid competing deployment systems.

Why globally disabling every update is usually the wrong tool

WordPress provides a global constant:

define( 'AUTOMATIC_UPDATER_DISABLED', true );

The official WordPress documentation explains that this disables the automatic updater entirely.

That can be appropriate in specialized environments, but it is an extremely broad control.

It disables unrelated updates too

If the problem is one plugin, globally disabling automatic updates affects far more software than necessary.

You may unintentionally stop:

• core background updates;
• plugin automatic updates;
• theme automatic updates;
• translation updates.

WordPress explicitly notes that disabling background updates globally is strongly discouraged because automatic minor and translation updates form part of the platform’s maintenance and security strategy.

It can hide an organizational problem

A global update freeze can remain forgotten inside wp-config.php long after the original compatibility issue has disappeared.

Months later, administrators may wonder why nothing updates automatically.

Selective exceptions are easier to reason about because each exception has a specific component and reason.

How to disable automatic updates for one plugin

The simplest method for ordinary WordPress installations is the native plugin auto-update control.

Using the WordPress dashboard

1. Open Plugins → Installed Plugins.
2. Locate the plugin you want to control.
3. Find the Automatic Updates column.
4. If automatic updates are enabled, click Disable auto-updates.

The plugin will continue showing available updates, but WordPress will no longer install ordinary automatic updates for that plugin through the standard per-plugin mechanism.

Using WP-CLI

WP-CLI also provides official commands for controlling plugin auto-updates.

For example:

wp plugin auto-updates disable plugin-slug

You can verify the current state with:

wp plugin auto-updates status plugin-slug

This is particularly useful for managed fleets, scripted deployments and staging environments.

How to disable automatic updates for one theme

WordPress offers equivalent behavior for themes.

Using the WordPress dashboard

1. Open Appearance → Themes.
2. Open the details for the relevant theme.
3. Locate the automatic-update control.
4. Disable auto-updates for that theme.

Again, the update itself can remain visible while automatic installation is paused.

Using WP-CLI

WP-CLI provides theme-specific automatic-update commands as well.

wp theme auto-updates disable theme-slug

This allows theme update policy to be managed separately from plugin update policy.

How developers can selectively control automatic updates

WordPress exposes filters specifically for controlling whether each update type is installed automatically.

The official auto_update_{$type} hook documentation lists:

• auto_update_core;
• auto_update_plugin;
• auto_update_theme;
• auto_update_translation.

Disable automatic updates for one plugin programmatically

A developer can inspect the plugin update object and return false only for the intended plugin.

add_filter(
    'auto_update_plugin',
    function ( $update, $item ) {
        if ( isset( $item->plugin ) && 'example-plugin/example-plugin.php' === $item->plugin ) {
            return false;
        }

        return $update;
    },
    10,
    2
);

This preserves the normal decision for every other plugin.

That is fundamentally different from:

add_filter( 'auto_update_plugin', '__return_false' );

which prevents automatic updates for every plugin processed by that filter.

Where should this code live?

The WordPress documentation recommends placing update-control filters in a plugin, preferably a must-use plugin for site-level configuration.

Do not place add_filter() calls directly inside wp-config.php.

At that point WordPress is not fully loaded, and the documentation specifically warns that doing so can cause conflicts with other contexts such as WP-CLI.

Why a must-use plugin can be appropriate

A must-use plugin provides a central site-level location for update policy that is not tied to the active theme.

This prevents a theme change from silently removing the update rule.

However, custom update-control code still needs documentation. Otherwise the next administrator may not understand why a plugin refuses to update automatically.

Notifications and automatic installation are separate concerns

This distinction is one of the most important parts of selective update management.

You may want to prevent automatic installation without hiding the fact that an update exists.

Keeping notices visible is often safer

If administrators can still see that a plugin has an update available, they are more likely to review it.

If both the automatic update and the update notice disappear, the component can silently become outdated.

For production workflows, a useful policy can therefore be:

• show available updates;
• disable automatic deployment for selected critical plugins;
• test those releases on staging;
• apply approved versions manually;
• keep automatic updates enabled for low-risk components where appropriate.

Removing an update from the update transient is a stronger intervention

WordPress stores update information in transient-style structures used by the administration and update system.

A plugin can filter those structures and remove individual update entries.

Doing that can suppress the visible update itself, not merely prevent automatic installation.

That behavior should therefore be used more carefully because administrators may no longer see that the installed component has fallen behind.

How TheOneWP handles selective update control

TheOneWP provides a dedicated Disable Updates module.

Its purpose is broader than WordPress’s ordinary per-plugin auto-update switch because it centralizes several categories of update control.

Core update control

The verified module provides control over WordPress core update behavior independently from plugin and theme controls.

This allows administrators to define a deliberate policy instead of disabling the entire updater indiscriminately.

Translation update control

Translations are handled separately.

This matters because a site may have a valid reason to hold software versions while still allowing translation updates.

Per-plugin control

The module can target individual installed plugins.

A selected plugin can be held back without automatically applying the same rule to every other plugin.

Per-theme control

The same principle applies to themes.

An individual theme can be excluded from the normal update path while other themes remain unaffected.

Automatic update vetoes

The verified implementation also prevents silent automatic updates for components that have been explicitly disabled.

This is important because merely hiding a dashboard notice would not be sufficient if the background updater could still install the version later.

Update visibility

The module can also control update information presented through WordPress’s update system for held components.

That means using the feature requires operational discipline.

If you intentionally suppress an update, maintain another process for checking whether the held component has received important security or compatibility fixes.

When selective update disabling becomes dangerous

The feature itself is not the risk. Forgetting why the feature was enabled is.

A compatibility hold becomes permanent

A plugin is paused because version 4.2 conflicts with custom code.

The issue is never revisited.

Six months later, the site is still running 4.1 even though versions 4.3, 4.4 and 4.5 have been released.

The original compatibility issue may no longer exist, but the site continues accumulating update debt.

A security fix is missed

The plugin being held back may later receive a vulnerability fix.

If update visibility has also been suppressed, administrators may not notice the release through normal WordPress screens.

For that reason, held plugins should be included in a separate review process.

See The Risks of Not Updating WordPress Plugins.

Someone assumes disabled auto-updates mean no manual maintenance is required

Disabling automatic updates transfers responsibility from automation to humans.

It does not remove the responsibility.

The site still needs:

• release monitoring;
• security advisory review;
• staging tests;
• manual deployment;
• post-update verification.

Build a safe policy for held WordPress updates

Every selectively disabled update should have a reason, an owner and a review point.

Record the exception

At minimum, document:

• component;
• installed version;
• date the update was disabled;
• reason;
• person responsible;
• known security implications;
• next review date.

Use staging as the resolution path

If the hold exists because of compatibility concerns, the next step should normally be testing, not indefinite waiting.

Use Building a Staging-First WordPress Update Workflow to turn the hold into a controlled deployment process.

Review security-sensitive holds more frequently

A plugin handling authentication, uploads, payments or public API requests deserves greater attention than a small admin-only utility.

Update policy should reflect the consequences of a vulnerability in the component.

Remove abandoned dependencies

If a plugin cannot be updated because it is no longer maintained, selectively disabling its updates does not solve the underlying problem.

Evaluate replacement or removal.

Selective updates vs. global update controls

Native WordPress per-plugin controls

Best when the requirement is simply to disable ordinary automatic updates for a particular plugin while keeping update availability visible.

Advantages include:

• built into WordPress;
• simple;
• clear in the Plugins screen;
• easy to reverse.

WP_AUTO_UPDATE_CORE

Best when you need explicit control over WordPress core automatic-update policy.

It does not provide per-plugin control.

AUTOMATIC_UPDATER_DISABLED

Best reserved for environments where the entire WordPress background updater genuinely needs to be disabled.

It is too broad when the problem concerns one plugin.

WordPress filters

Best for developer-managed policies that need logic based on plugin identity, environment or other conditions.

They are powerful but require documentation and code maintenance.

TheOneWP Disable Updates

Useful when administrators want centralized control over multiple update categories and individual plugin or theme exceptions without maintaining custom snippets.

Selective WordPress update checklist

• Identify exactly which update behavior needs to be disabled.
• Do not globally disable updates when only one component needs a hold.
• Keep automatic core security maintenance enabled unless there is a documented reason not to.
• Use WordPress’s native per-plugin auto-update controls where they are sufficient.
• Use native per-theme controls where they are sufficient.
• Use WP_AUTO_UPDATE_CORE only for core update policy.
• Understand that AUTOMATIC_UPDATER_DISABLED affects the entire automatic updater.
• Do not put WordPress filter calls directly in wp-config.php.
• Use a plugin or must-use plugin for custom update filters.
• Prefer component-specific filters over blanket filters.
• Document every update hold.
• Record the currently installed version.
• Record the reason for the exception.
• Assign an owner.
• Set a review date.
• Monitor security advisories for held components.
• Test blocked updates on staging.
• Create a backup before higher-risk production updates.
• Remove the hold when compatibility testing succeeds.
• Replace abandoned components that cannot be safely updated.

Related guides

• Building a Staging-First WordPress Update Workflow
• The Risks of Not Updating WordPress Plugins
• WordPress Staging Site Best Practices
• WordPress Maintenance Mode Best Practices
• Settings Export vs. Full Backup: What’s the Difference?
• Standardizing WordPress Configuration Across Client Sites
• Why Hide Your WordPress Version Number?
• How Attackers Fingerprint WordPress Sites

Final recommendation

Selective WordPress update control is useful when it supports a deliberate deployment process.

It is dangerous when it becomes a mechanism for silently freezing software.

If one plugin needs additional testing, disable its automatic updates rather than shutting down the entire WordPress updater. If a theme release is temporarily incompatible, hold that theme while unrelated plugins continue following their normal maintenance policy. If core updates require different handling, control them independently.

The key is precision.

Use the narrowest control that solves the actual problem.

Then document the exception, monitor the held component, test the update in staging and remove the restriction when the reason for it no longer exists.

Automatic updates shift part of maintenance responsibility to WordPress. Disabling them shifts that responsibility back to you.

That can be completely reasonable, but only when someone is actively carrying that responsibility.

The goal should never be to stop WordPress from changing forever.

The goal is to decide deliberately which changes happen automatically, which changes require testing, and when a temporary hold is safe to remove.