Guide WordPress

How to disable plugins when you cannot log in

Rename the plugin folder over FTP, or edit the database directly, when a broken plugin has locked you out of the dashboard itself.

iFastHosting Support Team Updated 26 August 2026 6 min read Intermediate

When a plugin breaks a site badly enough, it can take the dashboard down with it, which leaves you unable to reach the Plugins screen where you would normally switch it off. All three methods below work entirely outside WordPress's own interface, so they still work even when wp-admin will not load at all.

Method 1: rename the plugin folder

The fastest option, and the one to try first. WordPress checks for a plugin's main file at a specific path, and if that path no longer exists, it deactivates the plugin automatically rather than erroring.

Connect over FTP or open the file manager
See connecting with FTP if you have not set this up before.
Navigate to wp-content/plugins
You will see one folder per installed plugin.
Rename the suspect folder
Add anything to the name — plugin-name-disabled is clear and easy to reverse. WordPress can no longer find the plugin's files and deactivates it on the next page load.
Reload the site
If it recovers, that plugin was the cause. Rename the folder back to reactivate it, or leave it renamed while you look for an update or a replacement.

Not sure which plugin is at fault?

Rename the entire plugins folder itself, to something like plugins-disabled, then create an empty folder named plugins in its place. This deactivates every plugin at once. If the site recovers, rename your original folder back and reactivate plugins one at a time — checking the site after each — until the problem returns and you have found the specific one responsible.

Method 2: deactivate through the database

Slightly more involved, but it deactivates the plugin properly through WordPress's own records rather than just hiding its files, which some people prefer.

Open phpMyAdmin
Found in the databases section of your control panel — see using phpMyAdmin.
Open the wp_options table
Search the option_name column for active_plugins.
Edit its value
The value is a serialized PHP array listing every active plugin's path. To deactivate everything at once, replace the entire value with a:0:{}, which represents an empty array.
Save and reload the site
Every plugin is now deactivated. Reactivate the ones you need from the Plugins screen once you can log in again.

Do not try to remove a single entry by hand

The value is a serialized array with a length prefix on every item. Deleting or editing just one plugin's entry without recalculating the surrounding array structure corrupts the whole value and can cause new errors. Replace the whole thing with an empty array instead, or use Method 1 to target a single plugin.

Method 3: use WP-CLI

If your hosting gives you SSH access and WP-CLI is available, this is the cleanest option, because it uses WordPress's own deactivation logic rather than working around it.

# Deactivate one plugin
wp plugin deactivate plugin-folder-name

# Deactivate everything
wp plugin deactivate --all

See using WP-CLI on your hosting if you have not used it before — it needs to be run from within the site's own directory over SSH.

Which method to use

Situation	Use
You know which plugin is the problem	Method 1 — rename just that folder
You do not know which plugin, and want to test one at a time	Method 1 — rename the whole plugins folder, then reintroduce plugins individually
You prefer working through the database	Method 2
You have SSH access and are comfortable with the command line	Method 3 — cleanest and least error-prone

Once the site is back

Confirm the site loads normally with the problem plugin disabled before doing anything else. Then decide what to do about that plugin: check for a newer version that fixes the issue, check whether it conflicts with something else you updated recently, or replace it with an alternative if it is no longer maintained. Reactivating it without addressing whatever caused the failure just reproduces the same problem.

If none of these methods gets the site loading again, the cause may not be a plugin at all — see fixing the WordPress white screen of death for the broader troubleshooting process, including how to check the theme and the server's PHP error log.

Why WordPress behaves this way

WordPress keeps a list of active plugins in the database, but it does not trust that list blindly — on every page load it checks that the file each entry points to still exists before trying to run it. This is a safety mechanism, not a bug: it means a plugin folder deleted directly on the server, or an update that fails halfway through and leaves files missing, does not permanently break the site. The moment the expected file is gone, WordPress simply stops trying to load it. Renaming a folder is exploiting that same check deliberately and safely, rather than working around anything WordPress did not intend.

This is also why the fix rarely requires touching the database directly unless you specifically want to. The files are the source of truth for whether a plugin can run at all; the database entry only controls whether WordPress attempts to.

Avoiding the same problem next time

Take a backup before any plugin update, not just before installing something new — an update is exactly as capable of breaking a site as a fresh install. See backing up a WordPress site.
Update plugins one at a time rather than all at once, so a failure points clearly at a single cause.
Keep FTP or SSH credentials somewhere you can reach even if wp-admin is down. Every method in this guide depends on having some way into the server that does not go through WordPress itself — losing that access alongside a broken plugin turns a five-minute fix into a support request.