How to block plugin installs on a WordPress site

Every plugin you install is code with the full run of your site: file access, database access, whatever admin capabilities it asks for. That’s a fair trade when you chose the plugin deliberately. It’s a much worse trade when the install happened by accident, by a support tech poking around, or by whoever got into the account after you did. If you’re looking at how to disable plugin installation on a WordPress site, you’re probably not trying to stop yourself — you’re trying to close a door that keeps getting opened by someone else.

The problem, honestly

Every plugin install is attack surface, full stop. It doesn’t matter how reputable the plugin looks in the directory; the moment it’s active, it can read your database, write to your filesystem, and register anything a logged-in admin can register. Most installs are fine. The ones that aren’t are exactly why this matters.

Two situations bring people here. The first is the agency handoff: you build a clean site, hand it over, and six months later it comes back broken — a page builder or “SEO booster” got installed along the way, nobody remembers why, and now three things on the front end don’t render. The second is worse. When an admin account gets compromised, installing a plugin is one of the first moves an attacker makes, because a plugin is a much more durable foothold than a single edited file. It survives a core update. It can look like anything. And once it’s active, “clean up the hack” means auditing every plugin on the site, not just the one that got in.

Blocking installs doesn’t stop every attack. It closes one of the easiest, most reliable ones.

The standard way to block plugin installs, and its real trap

Search for how to stop WordPress plugin installs and you’ll land on one answer almost everywhere: add this to wp-config.php.

define( 'DISALLOW_FILE_MODS', true );

It works exactly as advertised. With it set, the Add New Plugin screen disappears, the Upload Plugin button is gone, the plugin and theme editors are gone, and — this is the part people skip past — updates are gone too. DISALLOW_FILE_MODS doesn’t distinguish between a new install and an update to something already there. It kills both, for every role, including yours.

That’s the trap. You didn’t just block a hypothetical bad install — you blocked the security update for the plugin you’re already running, the one that matters most. And turning the constant back off requires editing wp-config.php directly, which means FTP, SFTP, SSH, or a hosting file manager. If the person you handed the site to only has a wp-admin login — which is the whole point of most handoffs — they can’t undo this themselves. They’re stranded until you or a developer opens the file for them.

There’s one situation where that’s exactly the right trade. On fully managed hosting where a developer owns every deploy — plugin updates go through a staging pipeline, code review, and a controlled release, not a click in wp-admin — DISALLOW_FILE_MODS is correct, not a mistake. The dashboard was never supposed to be where installs happen on that kind of site. For everyone else, it’s a constant that solves the install problem by also breaking the thing you needed to keep working.

The middle ground: capabilities by hand

WordPress already gates plugin installs behind capabilities — install_plugins, update_plugins, delete_plugins — and by default only the administrator role holds them. So the constant is usually solving a problem that only shows up once an agency handoff gives the client’s account the administrator role, often because a page builder or theme demanded it during setup. In that situation, the real fix isn’t blocking file mods globally, it’s not handing out those capabilities in the first place, or removing them once they’re there.

You can strip a capability from a role with remove_cap() in functions.php, or through a role-editor plugin that gives you checkboxes instead of code. Both work. Both are also fiddlier than they sound. Hand-edited capability changes give you no confirmation and no undo — get the role or the capability name wrong and nothing errors, it just silently doesn’t do what you meant. Role-editor plugins are friendlier but add another plugin to a site where the whole goal was fewer moving parts, and reversing a change usually means remembering exactly which boxes you unchecked six months ago rather than clicking one switch back.

There’s a smaller, safer sibling worth knowing about here too: DISALLOW_FILE_EDIT. It’s easy to confuse with DISALLOW_FILE_MODS because the names are close, but the scope is much narrower — it only removes the Plugin Editor and Theme Editor screens, the in-dashboard code editors. It doesn’t touch installs or updates at all. If code edits from the dashboard are the actual risk you’re worried about, that’s the constant for it, not DISALLOW_FILE_MODS. Locking installs and locking the code editor are two different problems with two different answers.

What a good lock actually does

The approach that avoids both failure modes runs at a different layer entirely: filter the capability check itself, at runtime, instead of editing the role or blocking file writes wholesale. WordPress runs every current_user_can() check through the user_has_cap filter, which means you can remove install_plugins and update_plugins from the effective capability set for the request without ever touching what’s stored on the role.

That distinction matters more than it sounds like it should. Nothing gets written to the database, so there’s no capability edit sitting in wp_usermeta that someone has to remember to reverse later. Turn the lock off from the dashboard, and the filter stops running — the capability is back on the next page load, exactly as if it had never left. No wp-config file, no FTP session, no “call your developer” moment. Whoever has an admin account can always undo this themselves, which is the one requirement a lock like this can’t skip: it should never strand the owner.

The other piece a capability filter gets you that a blanket constant can’t: an allowlist. You can block new installs and updates for everything except a small, named list — a security plugin you still want patching itself, say — so the plugin doing the protecting doesn’t get frozen along with everything else. DISALLOW_FILE_MODS can’t make that distinction. It’s on or off for the whole site.

The shortcut

Installation Lockdown is one of the locks in WP Pro Admin, live now in the 2.x releases. It blocks plugin and theme installs, uploads, and updates — capability-based, the way described above, not DISALLOW_FILE_MODS. Turn it on and the install and update screens disappear for everyone without the capability; turn it off from the dashboard and they’re back, nothing left over in the database either way. The optional allowlist keeps a security plugin of your choice updating even while the lock is on, so protection and lockdown don’t work against each other.

It’s the same reversibility promise behind every lock in the plugin, covered in more detail here: nothing a feature does should outlive switching it off. If you’re also looking at a specific plugin whose updates — not installs — you want to stop without touching anything else, that’s a related but different problem, covered in how to stop a WordPress plugin from updating. WP Pro Admin is free, and Installation Lockdown ships in it today.