Block Plugin Installs With DISALLOW_FILE_MODS

What this check and mySites.guru tool looks at on your site

This check reads your site’s wp-config.php for the DISALLOW_FILE_MODS constant and confirms it’s both defined and set to true. If it’s missing, or present but false, the check fails. Because the constant also switches off automatic updates, a passing result on this check is worth cross-referencing against how current your plugins and core version actually are, rather than assuming a strict setting alone means a well-maintained site.

Why a compromised admin reaches for the plugin installer first

If an attacker gets administrator access to a WordPress site, whether through a leaked password, a phished login, or a privilege-escalation bug in another plugin, installing a malicious plugin is usually the very first thing they do. It’s the most reliable way to get persistent code execution: upload a plugin, activate it, and it runs on every page load from then on, survives a core update, and often disguises itself well enough to sit unnoticed for months. DISALLOW_FILE_MODS removes that option entirely by disabling plugin and theme installs, updates and deletions through wp-admin, for every account, compromised or not.

It’s a genuinely stricter setting than DISALLOW_FILE_EDIT, and it implies it: anywhere DISALLOW_FILE_MODS is set to true, the plugin and theme editor is already gone too, whether or not you’ve separately set the narrower constant. That’s the whole trade-off in one sentence: this is the strongest single setting against a compromised admin account installing anything through the dashboard, and it’s stricter precisely because it also removes some things you might still want.

The two constants exist as separate options for a reason, and it’s worth choosing deliberately rather than assuming stricter is always better. DISALLOW_FILE_EDIT alone is a sensible middle ground for a site where an agency or a client still needs to install plugins occasionally through wp-admin, but nobody should ever need the raw code editor. DISALLOW_FILE_MODS is the right call for a site that’s genuinely finished changing, where any install or update is a deliberate, occasional event handled by whoever manages the site, not routine admin-panel work.

What you give up in exchange

The trade-off worth being explicit about is automatic updates. WordPress’s own background update mechanism, the one that quietly applies core security patches without you doing anything, writes files to disk using the same code path that DISALLOW_FILE_MODS blocks. Setting the constant to true doesn’t just stop you installing plugins through wp-admin, it stops WordPress patching itself too. That’s a reasonable trade to make on a site you actively manage and keep an eye on, but it isn’t free, and a site left running with this constant set and nobody checking for security releases is worse off than one running ordinary auto-updates.

How to fix it

1. Connect to your site via SFTP, SSH, or your hosting file manager, and open wp-config.php in the site root. This is the same file DISALLOW_FILE_EDIT lives in, so if you’ve already set that constant, you’re adding this one alongside it, not replacing it.
2. Add the constant above the /* That's all, stop editing! Happy publishing. */ line:

define( 'DISALLOW_FILE_MODS', true );

3. Confirm it took effect: log into https://yoursite.com/wp-admin, and check that Plugins → Add New and the plugin/theme editor screens are no longer available anywhere in the dashboard.
4. Decide how you’ll track security releases now that background updates are blocked. That might be watching the WordPress security release announcements, or relying on mySites.guru’s own version checks against your connected sites.
5. When you genuinely need to install or update something, remove or comment out the constant, make the change through wp-admin as normal, then set it back to true afterwards. Installing over SFTP or WP-CLI works at any time regardless of this setting, since neither goes through the code path the constant restricts.
6. On a multisite network, this constant lives in the single, shared wp-config.php, so setting it applies to every site in the network in one go rather than needing repeating per site.

What mySites.guru does about it

mySites.guru checks every connected WordPress site for this constant on each snapshot, twice a day, and can set DISALLOW_FILE_MODS to true in wp-config.php with one click, across every connected site at once, rather than editing each one by hand. Because the trade-off here includes losing automatic security updates, mySites.guru’s own version tracking on every connected site becomes the backstop that keeps you from missing one.