To disable a WordPress plugin from cPanel, open File Manager, browse to public_html/wp-content/plugins, and rename the plugin’s folder so WordPress can no longer find its main file. WordPress skips any active plugin whose file is missing, so your site loads again immediately. No dashboard access required.
public_html/wp-content/plugins, right-click the folder of the plugin you suspect, choose Rename, and add -disabled to the end. Reload your site. If you don’t know which plugin broke it, rename the whole plugins folder instead to switch every plugin off at once, then rename it back and re-activate them one at a time until the error returns.This is the standard rescue procedure for a white screen of death, a fatal PHP error, or a redirect loop that started right after a plugin update. You need three things: cPanel login details from your host, the name of the plugin you suspect (or the willingness to switch them all off), and five minutes. Everything below is reversible. Nothing here deletes content.
Step 1: Take a backup before you touch anything
Renaming a folder is low-risk. Hand-editing the database is not. Take a snapshot either way, because a broken site is much easier to recover from than a broken site plus a mangled database.
In cPanel, the Files group contains Backup and Backup Wizard. Backup Wizard walks you through a full account backup or a partial one, and the same section has File and Directory Restoration for rolling individual items back from local backup sources. Many hosts also bundle JetBackup or their own daily snapshot tool, which is usually faster than generating a fresh archive. If you would rather do it by hand, our guide to backing up a WordPress website manually covers the files-plus-database approach.
Step 2: Rename the plugin folder in File Manager
File Manager lives in the Files group of your cPanel Tools list. Open it and navigate to public_html/wp-content/plugins. If WordPress is installed in a subdirectory or on an addon domain, the path will differ, so look for the folder that contains wp-config.php and start from there.
Disable one plugin
- Right-click the plugin’s folder. cPanel builds the context menu from the item type, and for a folder it includes Rename.
- Change
contact-form-7tocontact-form-7-disabled. The suffix does not matter. What matters is that the path stored in the database no longer resolves. - Reload your site in a fresh incognito window to dodge caching.
If the site comes back, you found it. If nothing changes, rename that folder back and try the next suspect, or skip ahead and kill them all.
Disable every plugin at once
Rename wp-content/plugins to plugins-off. Every active plugin’s file path breaks at once. Then create a new empty folder named plugins so WordPress has somewhere to look, which keeps the Plugins screen from complaining about a missing directory.
Once you can log in to wp-admin, move the plugin folders back from plugins-off into plugins a few at a time and re-activate them, checking the front end after each batch. It is tedious and it is the fastest reliable way to identify the culprit.
What WordPress actually does when the files disappear
This is the part most tutorials skip, and it changes how you should sequence things.
On the front end, WordPress builds its plugin list in wp_get_active_and_valid_plugins(). Every entry in the active_plugins option has to pass a file_exists() check before it is loaded. Entries that fail are silently skipped. The database row is untouched, so if you rename the folder back the plugin is still active and picks up where it left off.
The admin side is stricter. When you open the Plugins screen, WordPress runs validate_active_plugins(), which calls validate_plugin() on each entry. A missing file returns the error code plugin_not_found with the message “Plugin file does not exist.”, and WordPress deactivates that plugin for real, removing it from active_plugins. You will see a notice naming each one.
wp_options, not in the plugin folder. Our breakdown of where WordPress plugin settings are stored explains exactly which rows hold what.Step 3: Edit active_plugins in phpMyAdmin (when the file trick is not enough)
Sometimes you want the plugin genuinely deactivated in the database rather than just unreachable, for example when a plugin registers a shutdown handler that fires before the file check, or when you are cleaning up after a botched migration. phpMyAdmin, in the Databases group of cPanel, is the tool for that.
Open phpMyAdmin, pick your site’s database in the left sidebar, open the wp_options table, and find the row where option_name is active_plugins. The Search tab is quicker than paging through hundreds of rows.
Reading the serialized array
The value is a PHP serialized array of plugin paths, relative to wp-content/plugins. Three active plugins look like this:
a:3:{i:0;s:19:"akismet/akismet.php";i:1;s:24:"wordpress-seo/wp-seo.php";i:2;s:9:"hello.php";}Read it left to right. a:3 means an array with three elements. Each element is an integer key (i:0) paired with a string (s:19) whose byte length is declared before the value. akismet/akismet.php is 19 characters, so the prefix reads s:19.
To deactivate Yoast SEO only, you must remove its element, renumber the remaining keys, and fix the count:
a:2:{i:0;s:19:"akismet/akismet.php";i:1;s:9:"hello.php";}unserialize() returns false, WordPress reads it as an empty plugin list at best and throws a fatal at worst, and you have replaced one broken site with a differently broken site. Count characters, not visual width. A trailing space inside the quotes counts. So does an accented character, which may be more than one byte.The safer trick: rename the option instead of editing it
You almost never need to hand-edit that string. Change the option_name instead:
- Click Edit on the
active_pluginsrow. - Change
option_nametoactive_plugins_backup. Leaveoption_valuecompletely alone. - Save. WordPress now finds no
active_pluginsoption, falls back to an empty array, and loads with zero plugins.
Log in, fix or delete the bad plugin, then rename the option back to active_plugins and everything reactivates exactly as it was. Zero character counting, zero serialization risk. One caveat: once WordPress writes a fresh active_plugins row of its own, you will have two rows fighting over the same name when you rename yours back, so delete the new empty one first. If you would rather do this with a proper query than with the phpMyAdmin table editor, see our guide to running a database query in WordPress.
Step 4: Use Terminal and WP-CLI if your host offers SSH
cPanel’s Terminal sits in the Advanced group and gives you in-browser command-line access inside your cPanel session. Not every host enables it; some require you to switch SSH access on first. If it is there, WP-CLI is by far the cleanest route.
cd ~/public_html
wp plugin list --status=active
wp plugin deactivate contact-form-7
wp plugin deactivate --all --exclude=akismet,wordpress-seoThis updates active_plugins properly, fires each plugin’s deactivation hooks, and prints what it did. Re-enable with wp plugin activate contact-form-7. If a fatal error is stopping WP-CLI from bootstrapping, add --skip-plugins so it loads WordPress without any plugins first.
Which method should you use?
| Method | Difficulty | Risk | Scope | Reversible? |
|---|---|---|---|---|
| Rename one plugin folder | Easiest | Very low | One plugin | Yes, rename it back |
| Rename the whole plugins folder | Easiest | Low | All plugins | Yes, but expect to re-activate |
| Rename the active_plugins option | Moderate | Low | All plugins | Yes, rename it back |
| Hand-edit the serialized array | Hard | High | One plugin | Only from a backup |
| wp plugin deactivate in Terminal | Moderate | Very low | One or all | Yes, wp plugin activate |
My order of preference: Terminal if the host offers it, folder rename if not, option rename when the folder rename is not enough, hand-editing serialized data never unless there is genuinely no alternative.
Re-enabling the plugin afterwards
Rename the folder back to its original name, exactly as it was. Plugin slugs are case-sensitive on Linux, and Contact-Form-7 is not contact-form-7. Then go to Plugins in wp-admin and activate it if it is showing as inactive.
If the plugin was the actual cause, do not just switch it back on and hope. Update it, check whether your PHP version is supported, and if it is a plugin you cannot live without, reproduce the failure on a copy of the site first. Building that copy is a ten-minute job with a modern local app, which is exactly what our walkthrough on installing WordPress on a local host covers.
Troubleshooting
Still a white screen after renaming every plugin
Then it is not a plugin. Two usual suspects. First, the theme: rename your active theme’s folder inside wp-content/themes, and WordPress falls back to a default theme if one is present. Second, must-use plugins: anything in wp-content/mu-plugins loads on every request, is not listed in active_plugins, and cannot be deactivated from the dashboard at all. Managed hosts and security plugins both drop files there. Rename that folder too. Also check wp-content/object-cache.php and wp-content/advanced-cache.php, which are drop-ins that load early and outlive plugin deactivation.
You cannot find the right database, or wp_options does not exist
Your table prefix is not wp_. Open wp-config.php in File Manager and look for the $table_prefix line and the DB_NAME constant. Many one-click installers randomize the prefix to something like wp_a7x2_, so the table you want is wp_a7x2_options. Accounts with several installs will show several databases, and DB_NAME is the only reliable way to tell which is which.
Multisite behaves differently
On a network, per-site activations still live in each site’s options table (wp_options for site 1, wp_2_options for site 2, and so on). Network-activated plugins do not appear there at all. They are stored in wp_sitemeta under the key active_sitewide_plugins, and that array is keyed by plugin path rather than by integer, so the serialized structure looks different. Renaming the plugin folder still works, and wp plugin deactivate --network is the tidy way to do it.
The site loads but redirects somewhere strange
Check the siteurl and home rows in wp_options, and check whether the plugin left rules in .htaccess. Security and caching plugins write there, and those rules survive a folder rename. File Manager hides dotfiles by default, so enable “Show Hidden Files” in its Settings.
Frequently asked questions
Will renaming the plugin folder delete my settings?
No. Plugin settings live in the database, mostly as rows in wp_options, and renaming a folder does not touch them. When you rename the folder back and re-activate, your configuration is still there. Deleting a plugin from the Plugins screen is what can trigger cleanup, and only if the developer wrote an uninstall routine.
Can I just delete the plugin folder instead of renaming it?
You can, and it works, but renaming is strictly better while you are diagnosing. A rename is instant to undo. A delete means re-downloading the plugin, and if it was a premium plugin you may need to dig out a licence key first. Delete only once you are certain you no longer want it.
How do I know which plugin caused the error?
Read the error before you guess. Set WP_DEBUG and WP_DEBUG_LOG to true in wp-config.php and read wp-content/debug.log, or check your host’s error log in cPanel’s Metrics group. A PHP fatal error names the exact file, which usually names the plugin.
Does WordPress email me when it deactivates a broken plugin?
Sometimes. WordPress has a recovery mode that emails the site administrator when a plugin or theme causes a fatal error, with a link that lets you log in with the offending extension paused. Check the inbox on the admin email address before you open cPanel at all; it may save you the trip.
Is there a WordPress manager inside cPanel that does this for me?
On some hosts, yes. Various providers bundle a WordPress management tool in the Software group that can deactivate plugins, clone sites, and roll back updates. Availability depends entirely on your host, so check the Software group in your own account rather than assuming.
Wrapping up
Renaming the plugin folder in cPanel’s File Manager solves this in nearly every case, and it is the method I would reach for first every time. It takes seconds, it needs no SQL, and undoing it is another rename. Keep the database out of it unless the file approach genuinely fails, and if you do open phpMyAdmin, rename the active_plugins option rather than editing the serialized value inside it.
Two habits make this a non-event next time. Have a current backup before every plugin update, and keep a local or staging copy where updates land first. If you want to read the primary sources, WordPress documents validate_plugin() and the wp plugin deactivate command, and cPanel documents File Manager in full.
