How to Disable a WordPress Plugin When You Can't Access Your Dashboard

A WordPress plugin can cause a fatal error, a redirect loop, a blank screen or a login problem that keeps you out of the dashboard entirely. When that happens you can almost always recover the site without deleting the plugin, because WordPress deactivates any plugin it can no longer find on disk.

Work in this order: identify what changed immediately before the problem appeared, confirm you have a backup, then disable the plugin by a method that does not depend on wp-admin. Four methods below, from safest to last resort.

When disabling a plugin is the right move

Disable a plugin temporarily when the problem started immediately after you installed, activated or updated it, and you are seeing a fatal PHP error, a white screen, a broken front end, an unreachable login page, or an error message that names a file inside wp-content/plugins/.

Not every WordPress error is a plugin

Theme code, a core update, a PHP version change, a hosting memory limit and a database problem all produce the same symptoms. If renaming a plugin folder changes nothing, stop renaming folders and read the error instead — the white screen of death and a 500 internal server error cover the non-plugin causes.

1. Rename the plugin folder in your hosting file manager

If your hosting account has a file manager, this is the fastest route and it needs no software installed.

Open your hosting control panel and launch the file manager.
Navigate to your WordPress install and open wp-content/plugins/.
Find the folder belonging to the suspected plugin.
Rename it — example-plugin becomes example-plugin-disabled.
Reload the front end and the login page.

WordPress cannot find the plugin at its registered path, so it deactivates it and carries on. Renaming is reversible, which is the whole point — write the original folder name down before you change it.

2. Do the same over FTP or SFTP

Same operation, different transport. Connect with your client, open wp-content/plugins/, rename the suspected directory, then reload the site and test the login page.

Use SFTP rather than plain FTP where your host offers it, since FTP sends your credentials unencrypted. If you are not sure which you are using, check the port: 21 is FTP, 22 is SFTP.

3. Deactivate with WP-CLI

With shell access this is the cleanest method, because it deactivates the plugin properly rather than orphaning it, so its deactivation hooks still run.

# One plugin
wp plugin deactivate plugin-slug

# Everything, while you work out which one it is
wp plugin deactivate --all

# Not sure of the slug? List what is active
wp plugin list --status=active --field=name

After the site comes back, reactivate one plugin at a time and test between each one. That turns a vague failure into a named culprit, usually within a few minutes — troubleshooting a WordPress plugin conflict step by step covers doing it methodically on a site you cannot take offline.

4. The database, only as a last resort

When you have neither file access nor WP-CLI, the active plugin list lives in the options table under active_plugins. Do not assume the prefix is wp_ — read it from wp-config.php if you can.

active_plugins is a serialized PHP array

Each entry carries a byte-length prefix, so deleting a plugin’s path by hand in phpMyAdmin corrupts the whole value and deactivates every plugin at once — or breaks the option entirely. Take a verified database backup first, and if you must edit it, replace the value with a:0:{} to deactivate everything cleanly rather than trying to surgically remove one entry.

What to do once you are back in

Read the actual error. Your host’s error log names the file and line. If you cannot find one, turn on debug logging — enabling WordPress debugging and reading error logs safely shows how to do it without displaying notices to visitors.

Check versions before reactivating. Most fatal errors on activation are a plugin meeting a PHP version it does not support. Checking and updating PHP safely covers reading what you are really running.

Test on staging, not production. If the plugin is essential and there is no newer version, reproduce the failure on a copy with other plugins off and a default theme active.

Restore the folder name deliberately. Renaming it back does not reactivate the plugin, but it does make it activatable again. Do that only when you know why it broke.

Sometimes the plugin is not broken, just incompatible

Worth knowing, because it looks like a plugin fault and is not. A plugin can be perfectly functional and still be blocked from working alongside a feature you have switched on, and WordPress will not always tell you which way round the conflict runs.

WooCommerce stores meet this most often with order storage. Under WooCommerce → Settings → Advanced → Features, if the High-Performance Order Storage option is greyed out, WooCommerce has found an active plugin that declares itself incompatible with the feature and it names that plugin on the screen. Deactivating it is not the fix on its own — you need to decide whether to update it, replace it, or leave the feature off. WooCommerce HPOS migration: risks and real gains walks through that decision and how to audit plugins before you flip anything.

If disabling the plugin changes nothing

Then the plugin was not the cause, and continuing to rename folders will cost you an afternoon. Look at what else changed: a theme edit, a core update, a PHP version bump by your host, database connectivity, a memory limit. Two specific errors have their own diagnosis paths — the allowed memory size exhausted error and error establishing a database connection.

On a site that takes money, restore from a backup or work on staging rather than making repeated changes to live files, and bring in your host or a developer earlier than feels necessary.

Quick recovery checklist

Identify what changed immediately before the failure.

Confirm a backup exists before touching anything.

Rename the suspected folder in the file manager or over SFTP.

Prefer wp plugin deactivate where you have shell access.

Read the error log before reactivating anything.

Reactivate one plugin at a time and test between each.

Replace a plugin that has not been updated in two years rather than nursing it.

Frequently asked questions

Does renaming a plugin folder delete its settings?

No. Settings live in the database, not in the plugin folder, so renaming the directory leaves them untouched. Rename it back and reactivate and your configuration is still there. Deleting the plugin through wp-admin is the action that may remove its data, and only if the plugin chooses to clean up after itself.

How do I disable all plugins without access to the dashboard?

Rename the whole wp-content/plugins directory to plugins-off, which deactivates everything at once, then create an empty plugins folder so WordPress does not complain. Or run wp plugin deactivate --all if you have shell access. Renaming the folder back does not reactivate anything — you reactivate them one at a time from wp-admin.

Why is a plugin greyed out or marked incompatible instead of broken?

Some plugins declare, in code, that they do not support a particular feature — WooCommerce’s High-Performance Order Storage is the common example. The plugin works fine; it is the feature that gets blocked, and the host software names the offending plugin rather than failing. That is a compatibility decision to make deliberately, not an error to clear.

Is editing active_plugins in the database safe?

Only as a last resort, and only with a backup you have tested. The value is a serialized PHP array whose entries carry byte-length prefixes, so hand-editing it usually corrupts it. If you have to go in, set the whole value to a:0:{} to deactivate every plugin cleanly instead of trying to remove one line.

Find the conflicting plugin methodically

Turn on debug logging safely