--- title: How to stop a WordPress plugin from updating description: The "Disable auto-updates" link only stops automatic runs — a manual click still updates. How to really stop a WordPress plugin auto-update. pubDate: 2026-08-08 source: https://wpproadmin.com/guides/lock-plugin-version-wordpress/ --- Every version of a plugin you rely on is a promise the next version might not keep. Most updates honor that promise. Some don't, and the ones that don't tend to arrive at the worst moment — the night before a launch, in the middle of a campaign you can't pause to debug, or years after you installed something small and trusted, once it's changed hands. If you've ever needed to stop a WordPress plugin from auto-updating and discovered the toggle you clicked didn't actually do that, this is why, and what does. There are three real reasons people reach for a version lock. An update breaks something on a live site — a shortcode stops rendering, a checkout flow changes behavior, a CSS class gets renamed — and it happens right when you can least afford to investigate. A plugin gets sold, and the new owner starts shipping upsell banners or, worse, something closer to adware in a version bump you never asked for. Or a client site simply needs to hold still: mid-campaign, mid-audit, mid-anything, and every version bump is a variable you don't want. ## The auto-updates toggle doesn't stop a plugin from updating WordPress ships a per-plugin auto-update control on the Plugins screen. Find your plugin's row, look at the far-right column, and you'll see either **Enable auto-updates** or **Disable auto-updates**, depending on the current state. Click it and the label flips. This link controls exactly one thing: whether WordPress's background cron job updates that plugin on its own, unattended, usually overnight. Turn it off and that automatic run skips the plugin. That's the whole scope. It does not stop a manual update. If there's a new version available, the Plugins screen still shows an "Update Available" notice, the update still appears in the bulk-update checkboxes, and anyone with the right capability — you, tomorrow, half-remembering that you meant to check something — can still click **Update Now** and get it. The link doesn't hide the notice. It doesn't gray out the button. It only skips the unattended, scheduled run. That gap is where most "how do I stop a plugin from updating" searches go wrong: the toggle they found stops WordPress from updating the plugin *for* them, but not from updating it at all. ## Sitewide, code-level: still the same gap If you want the auto-update behavior to apply across every plugin at once rather than one row at a time, WordPress gives you two code-level options, and both have the identical limit. Add this to `wp-config.php`: ```php define( 'AUTOMATIC_UPDATER_DISABLED', true ); ``` This turns off WordPress's entire automatic background updater — plugins, themes, and (depending on version) minor core updates. It's a blunt, sitewide switch, and it's the constant developers reach for first. It still doesn't touch manual updates. The Update Available badge, the bulk-update checkbox, the one-click Update Now link on a single plugin's row — none of that goes away. You've disabled the cron job, not the update mechanism. The finer-grained version is the `auto_update_plugin` filter, which lets you approve or block auto-updates per plugin in code rather than through the UI: ```php add_filter( 'auto_update_plugin', function ( $update, $item ) { if ( $item->slug === 'the-plugin-you-want-frozen' ) { return false; } return $update; }, 10, 2 ); ``` Same ceiling as the UI toggle it replaces: it decides what the *cron job* does, not what a person clicking a button can do. ## Composer or git pinning: developer-land If your workflow already manages plugins as dependencies — Composer with WPackagist, or plugins vendored into a git repo and deployed rather than installed through wp-admin — you get real version pinning almost for free. Pin the version in `composer.json`, and a `composer update` won't touch it unless you bump the constraint yourself. That's a genuine lock: nothing updates the file on disk unless your deployment process does, and there's no wp-admin button that can override a file it doesn't manage. The catch is who this is for. It assumes a deploy pipeline, a developer maintaining `composer.json`, and — usually — the plugin update mechanism itself being bypassed entirely, since a Composer-managed plugin often shouldn't be receiving WordPress's own update checks at all. For a site owner using the dashboard day to day, this option doesn't exist. It's the right answer for a developer's stack, not a manual method available from wp-admin. ## The ethics of a version lock Here's the part that matters more than the mechanics: a version lock is a tool for holding still, not a tool for going dark. The moment a lock silently suppresses a *security* release — hiding the fact that a fix exists, not just declining to install it — it's stopped protecting the site owner and started working against them. That's not a hypothetical; it's the exact failure mode that makes "protective" plugins indistinguishable from the malware they claim to guard against. A lock that hides information from the person who owns the site isn't a lock anymore. It's a blindfold. A version lock done honestly has three properties. It stays **visible** — the site owner can always see that a plugin is locked and what version it's locked to, and if a newer version (security or otherwise) exists, that fact doesn't disappear just because the lock is on. It's **opt-in** — nothing gets frozen without a deliberate choice to freeze it. And it's **reversible** — unlocking is one click away, not a support ticket or a database dig. Any implementation that fails one of those three isn't giving you control. It's taking it away and calling it protection. A version lock that hides an available security update is the same betrayal wearing a different feature name. ## What this looks like end to end Put the three limits together and the shape of the problem is clear. The per-row toggle stops the automatic cron run but leaves the manual Update Now button live. The sitewide constant and filter do the same thing at a bigger scope — cron only. Composer or git pinning gives you a real lock, but only if your site is already deployed that way, which most WordPress sites aren't. Nothing available from the dashboard actually removes the ability to update a specific plugin while still letting every other plugin update normally, with the lock visible and reversible. ## The shortcut Version Lock is one of the six locks in WP Pro Admin, live now in the 2.x line. Pin a plugin to its currently installed version, and both paths close at once: the scheduled auto-update skips it, and the manual Update Now button is gone too, replaced with a locked indicator on that row. The lock stays visible in the dashboard the whole time it's on — you always know which plugins are frozen and to what version. If a security release ships for a locked plugin, that's shown, not swallowed; nothing about the lock hides that a fix exists. Unlocking is the same one click as locking. Nothing about it touches the database beyond the lock state itself, so turning it off leaves the plugin exactly where any other WordPress site would be. Version Lock only holds still a plugin that's already on the site — it has nothing to say about someone installing a new one. That's a related but different lock, covered in [how to block plugin installs on a WordPress site](/guides/block-plugin-installs-wordpress/). WP Pro Admin is a [free download](/) — not yet on wordpress.org — and every lock it ships, including this one, stays visible for as long as it's active.