Key facts at a glance
WordPress plugin troubleshooting in 2026
Last updated
- First, confirm it is a plugin
- Deactivate all plugins, or use Troubleshooting Mode. If the problem clears, a plugin is the cause, and you reactivate one at a time to find which.
- The tool that changes everything
- Troubleshooting Mode, in the official Health Check plugin, disables plugins and the theme for your session only. Visitors keep seeing the live site while you hunt the conflict.
- Plugins cause most white screens
- A fatal error in one plugin, or two plugins colliding, is the most common trigger of the WordPress white screen of death. Deactivating plugins is the first test.
- What a conflict really is
- Two pieces of code colliding: the same function name, a shared hook, a duplicated jQuery, or the same database option. The most severe throws a
Cannot redeclare functionfatal. - Locked out? Rename the folder
- Over SFTP, rename a plugin folder in
wp-content/pluginsto deactivate just it, or rename the whole plugins folder to disable all, settings preserved. - Plugins are the security frontier
- The large majority of WordPress vulnerabilities are found in plugins, so an abandoned or nulled plugin is a standing risk. Keep them updated and replace unmaintained ones.
Source: the Make WordPress support handbook on troubleshooting with the Health Check, the Health Check and Troubleshooting plugin, the Learn WordPress lesson on plugin and theme conflicts, the WordPress developer resources on common errors and JavaScript best practices, and our hands-on plugin repairs. Get a quote in 60 seconds →
Why plugins break WordPress
Plugins are what make WordPress do almost everything beyond publishing, and they are also third-party code from thousands of different authors, running together in the same space, on your server, sharing the same functions, hooks, scripts, and database. A typical site runs twenty to thirty of them. Most of the time they coexist quietly, but every one is another moving part that can fail on its own, collide with another, fall behind a PHP or WordPress update, or turn into a security hole when it stops being maintained. That is why plugins are, by a wide margin, the most common source of a broken WordPress site.
The reassuring part is that plugin problems are highly diagnosable. Because a plugin is a self-contained unit you can switch on and off, you can nearly always find the exact culprit by elimination, turning plugins off and back on and watching what changes. The whole craft of plugin troubleshooting is doing that elimination efficiently and safely, in the right order, without taking the live site down while you work, and then applying the specific fix once you know exactly which plugin, or which pair of plugins, is responsible.
It is worth separating two things that look identical from the outside. A single broken plugin fails on its own, no matter what else is active. A conflict only appears when two specific plugins, or a plugin and the theme, are active together, and each is fine alone. They present the same way, a white screen or a broken feature, but they need different fixes, and telling them apart is a key step in the method below.
Where plugin problems come from
Almost every plugin problem is one of these four. Naming yours points straight at the fix, and the conflict case gets its own full method in the next section.
A plugin broke the whole site
The most urgent. Activating or updating a plugin hit a PHP fatal error and the site went to a white screen or a critical error. Recover by deactivating that plugin, from the dashboard, the recovery email link WordPress sends, or by renaming its folder over SFTP, then read the debug log for the exact fatal.
A plugin conflict
Two plugins, or a plugin and the theme, that are each fine alone but break something when active together. It can be a fatal white screen or just one feature that stopped working. This is the case most worth understanding, because it is common, confusing, and entirely findable with the right method, which is the whole next section.
A plugin will not update, activate, or install
The plugin itself is stuck. An update fails on permissions, memory, or a disconnected premium license; an activation triggers a fatal from an unsupported PHP version or a missing dependency; an install is rejected as the wrong package. Each has a specific, quick fix once you read what the site is actually reporting.
A vulnerable, abandoned, or nulled plugin
A security problem rather than a crash. Because the large majority of WordPress vulnerabilities are in plugins, an outdated or unmaintained plugin becomes an open door over time, and a nulled plugin, a cracked paid one, frequently ships with malware. The fix is to update, replace with a maintained equivalent, and clean up if it was exploited.
How to find a plugin conflict
This is the heart of plugin troubleshooting, and the good news is that you do not need to read any code to find a conflict. You find it by elimination, and modern WordPress gives you a way to do the whole thing on a live site without a single visitor noticing. Here is the method we use, in order.
The isolation method, step by step
Switch to a default theme like Twenty Twenty-Five. If the problem persists, the cause is a plugin or the server, not the theme, and you can focus the hunt on plugins.
Use Bulk Actions then Deactivate on the Plugins screen, or rename the wp-content/plugins folder over SFTP if you are locked out. If the problem clears, a plugin is confirmed as the cause.
Turn the plugins back on one by one and repeat the test after each. The plugin that brings the problem back is the culprit, or one half of a conflicting pair.
Reactivate half your plugins and test, then narrow to the half that breaks and split again. This finds the culprit in a handful of tests instead of dozens.
Reactivate only the suspect plugin. If it breaks on its own, it is a faulty plugin. If it only breaks alongside another, it is a true conflict between the two, which changes the fix.
Enable WP_DEBUG and WP_DEBUG_LOG and reproduce the problem. The log names the file and line of the fatal, which often points straight at the conflicting code.
The old way of finding a conflict, deactivating plugins in wp-admin, disables those features for your visitors while you test. The modern way does not. The official Health Check and Troubleshooting plugin has a Troubleshooting Mode that gives your own logged-in session a clean WordPress, all plugins off and a default theme, while every visitor and other user keeps seeing your normal live site with everything running.
Once it is on, an admin-bar menu and a dashboard widget let you toggle individual plugins on and off and switch the theme, just for you. So you reactivate plugins one at a time and watch for the break in real time, on the real site, invisibly. This is the single best conflict-hunting tool there is, and it is how we diagnose conflicts on production sites without any risk to your visitors.
If a plugin has taken down wp-admin so you cannot reach the Plugins screen at all, deactivate over SFTP or your host file manager. To disable one plugin, rename its folder inside wp-content/plugins, for example adding -off, and WordPress deactivates it automatically because it can no longer find the file. To disable every plugin at once, rename the whole plugins folder to something like plugins-hold. Both preserve your settings, and neither deletes anything.
The types of conflict, and how each is fixed
Once isolation names the culprit, the conflict is almost always one of these. Knowing which one tells us the exact fix, and whether it is something to configure or a plugin to replace.
| Conflict type | What happens, and how it is fixed |
|---|---|
| PHP function-name collision | Two plugins define a function with the same name without a guard, so PHP throws a Cannot redeclare function fatal and the site white-screens. The fix is to deactivate one, or for a developer to wrap the declaration in a function-exists check or add a unique prefix. |
| JavaScript conflict | A plugin bundles its own copy of a library like jQuery instead of using the version WordPress already loads in no-conflict mode, breaking the shortcut other scripts depend on. The fix is to use the bundled library and correct dependencies, or dequeue the duplicate. |
| Hook and priority conflict | Two plugins hook the same action or filter, and one undoes the other or they run in the wrong order. The fix is to adjust the hook priority or decide which plugin should own that behavior. |
| Asset and enqueue conflict | Two plugins load clashing CSS or duplicate, incompatible versions of the same script, breaking a layout or a feature. The fix is to dequeue the duplicate so only one version loads. |
| Database or option conflict | Two plugins write to the same option or table and overwrite each other, corrupting settings or data. The fix is to separate the data or replace one of the plugins. |
| Plugin versus theme conflict | The theme functions.php collides with a plugin, often the same function name or hook. A quick test against a default theme tells you the theme is involved rather than a second plugin. |
Error and symptom reference
Find the exact message or symptom you see. Each row says what it means and where the fix is.
| Error or symptom | What it means and how to fix it |
|---|---|
| White screen or critical error after activating or updating a plugin | A PHP fatal in that plugin. The admin recovery email names the plugin and links to a safe login. Deactivate it, from the dashboard or by renaming its folder over SFTP, then read the debug log. |
| "Cannot redeclare function ..." fatal error | Two plugins, or a plugin and the theme, define the same function name. Deactivate one of the pair to get online, then replace it with a plugin that does not collide. |
| "The plugin could not be activated because it triggered a fatal error." | The plugin hit a fatal on activation, usually an unsupported PHP version or a missing dependency. Read the debug log, then update the plugin, adjust PHP, or install what it requires. |
| A plugin update fails, reverts, or times out | A file-permission, memory, or connectivity issue, or a premium license that is not connected. Confirm write access and memory, connect the license, or reinstall the plugin fresh. |
| Locked out of wp-admin by a plugin | Deactivate at the file level. Rename the single plugin folder in wp-content/plugins to disable just it, or rename the whole plugins folder to disable all of them, with settings preserved. |
| A feature stopped working after installing another plugin | A JavaScript or hook conflict between the two plugins. Isolate the pair with Troubleshooting Mode, then fix the specific clash rather than removing a plugin you need. |
| The plugin says it is incompatible with your PHP or WordPress version | The plugin needs a newer platform, or it is too old for PHP 8 and uses code PHP 8 removed. Update the plugin, or address the PHP version. |
| A plugin is flagged as vulnerable or no longer maintained | Most WordPress vulnerabilities are in plugins, so an outdated or abandoned one is a real risk. Update it, or replace it with a maintained equivalent, and scan if it was exploited. |
| The site slowed down after adding plugins | Too much plugin JavaScript on the main thread, or heavy queries. A performance problem more than a break. We audit and trim the plugin footprint. |
What we fix
Twelve problem areas cover almost every plugin emergency. We diagnose which one is actually yours rather than guessing.
Plugin Broke the Site
A blank page or critical error right after activating or updating a plugin. A PHP fatal. We deactivate the culprit, read the debug log, and move you to a patched version or a working alternative.
Plugin Conflict
Two plugins, or a plugin and the theme, colliding and breaking a feature or the whole site. We isolate the pair without downtime and resolve the specific conflict type.
Cannot Redeclare Function
The classic conflict fatal, two plugins defining the same function. We identify the pair, deactivate one, and replace it with a plugin that does not collide.
Plugin Will Not Update
An update fails, reverts, or times out from permissions, memory, or a disconnected license. We apply the update cleanly, or reinstall fresh without losing the plugin data.
Plugin Will Not Activate
Activation triggers a fatal error, usually a PHP version or a missing dependency. We read the log, fix the cause, and get the plugin running or find an alternative.
Plugin Will Not Install
The install fails or the package is rejected. Often the wrong zip, a size or memory limit, or a permissions issue. We install the correct package the right way.
JavaScript Conflict
A feature stops working after adding another plugin because their scripts collide. We find the clash, load the right library once, and restore the feature.
Locked Out by a Plugin
A plugin took down wp-admin so you cannot deactivate anything. We deactivate at the file level over SFTP, get you back in, and fix the cause.
Vulnerable or Abandoned Plugin
A plugin flagged as vulnerable, or one the author no longer updates. Since most WordPress vulnerabilities are in plugins, we patch or replace it with a maintained equivalent.
Nulled Plugin With Malware
A cracked premium plugin carrying injected code or a backdoor. We remove it, clean any infection, and set you up with a legitimate maintained version.
Too Many or Heavy Plugins
Plugin bloat dragging load times and responsiveness. We audit the footprint, remove dead weight, and flag the one or two plugins doing real damage.
Find the Conflict Without Downtime
We diagnose conflicts on the live site using Troubleshooting Mode, which isolates plugins for our session only, so your visitors never see a disabled feature.
Updating and vetting safely
Most plugin emergencies are preventable. A few habits stop the great majority of them, and they are the same steps we build into a maintained site.
Take a backup, or update on a staging copy first, before applying plugin updates to a busy live site, so a bad update is a restore rather than an emergency. This matters most for the plugins that touch a lot at once, a page builder, a store plugin, or a security plugin.
Outdated plugins are the leading source of vulnerabilities, so staying current is security, not just features. At the same time, deactivate and delete plugins you no longer use, because an inactive plugin is still code on the server that can be exploited and still something to maintain.
Prefer plugins that are actively maintained, updated recently, and compatible with your WordPress and PHP versions, and never install a nulled copy of a paid plugin, which is a common malware vector. One well-supported plugin beats three abandoned ones that each do a little.
The official Health Check and Troubleshooting plugin is worth having installed on any real site, so that when something does go wrong you can isolate a conflict in Troubleshooting Mode immediately, without downtime, instead of scrambling to deactivate plugins live.
Why specialist plugin work helps
Finding a plugin conflict is simple in principle and nerve-wracking in practice, because the honest method involves turning things off on a site people are using and hoping you remember exactly what you changed. Doing it safely, in the right order, without breaking a checkout or a form for real visitors, and then correctly telling a broken plugin apart from a two-plugin conflict, is exactly the kind of careful, methodical work most owners would rather not do on a live store. The skill is not knowing a secret, it is running the elimination cleanly, using Troubleshooting Mode so nothing is visible to customers, and recognizing the conflict type fast once the culprit is named.
We do this all day, so the process is the same every time. Confirm it is plugins by testing with them off, isolate the culprit with a binary search in Troubleshooting Mode so your visitors never see a disabled feature, read the debug log for the exact fatal, and then apply the right fix: deactivate and replace a colliding plugin, correct a script or hook conflict, recover access when a plugin has locked you out, or update and harden a vulnerable one. We charge a flat rate because we are fast at the elimination that would take an afternoon to do carefully by hand.
The 2-hour guarantee and the money-back promise are the enforcement. We do not get paid if we cannot fix the plugin problem for the agreed scope. Where the real answer is that two plugins simply cannot coexist, we tell you that and find you a replacement that keeps the feature without the conflict, rather than leaving you to choose between them.
Related fixes and hubs
Plugin problems often sit next to a broader WordPress issue. These are the pages for the ones that reach past the plugins themselves.
A specific two-plugin conflictThe focused diagnostic for a confirmed plugin conflict, the fastest path when you already know two plugins are fighting.
Fix a plugin conflict →White screen or critical errorA blank page for every visitor. Most often a plugin fatal, but also a theme, PHP, or memory. The debug log names the cause.
Recover a critical error →Plugin broke after a PHP 8 upgradeAn old plugin uses code PHP 8 removed and throws a fatal. Revert to get online, then update or replace the plugin and move forward.
Fix a PHP version break →A vulnerable or exploited pluginMost WordPress hacks start at a plugin vulnerability. We clean the infection, close the entry point, and harden the site.
Security and malware removal →It might be the theme, not a pluginThe theme repair hub. If a default theme clears the problem, the fault is a plugin; if not, the theme may be involved.
Theme repair hub →Everything WordPress repairThe parent hub for plugin, theme, update, and critical-error repairs across WordPress, with plugins as one part of it.
Visit the WordPress hub →Pricing and process
Send your site and the symptom
Use the quote form with your URL and what happened, a white screen after a plugin change, a broken feature, a failed update, or a lockout. A senior engineer replies with a flat-rate quote, usually within 30 minutes during business hours.
Approve, we start immediately
No scheduling step, no kickoff call. Approve the quote and we begin. You provide WordPress and hosting access through a secure link. The clock starts on the 2-hour guarantee.
Fixed and explained
We isolate the culprit without downtime, apply the right fix, confirm the site and its features work, and tell you exactly which plugin and why. Money back if we cannot fix it for the agreed scope.
WordPress plugin FAQ
A plugin broke my site, or I see a white screen after activating or updating a plugin. What do I do?
A blank page or a There has been a critical error message right after a plugin change is a PHP fatal error in that plugin, and the priority is to get back online by deactivating it. If you can still reach the dashboard, go to Plugins and deactivate the one you just changed. If the admin is down too, deactivate over SFTP or your host file manager by renaming that plugin folder in wp-content/plugins, adding something like -off to the end, which forces WordPress to deactivate it. Modern WordPress also emails the site administrator when a plugin causes a fatal, and that email names the plugin and includes a recovery link that logs you into a safe mode. Once you are back online, enable the debug log to read the exact fatal, which names the file and line, and from there the fix is a plugin update, a rollback, or replacing an abandoned plugin.
How do I find which plugin is causing the problem?
You isolate it by elimination. First rule out the theme by switching to a default theme, because if the problem persists the cause is a plugin or the server, not the theme. Then deactivate every plugin at once, using Bulk Actions then Deactivate, and confirm the problem clears, which proves a plugin is responsible. Now reactivate them one at a time, retesting after each, and the plugin that brings the problem back is the culprit. If you run a lot of plugins, use a binary search instead: reactivate half, test, and narrow to the half that breaks, which is much faster than one by one. When you find the plugin, reactivate only it to confirm whether it fails on its own or only in combination with another, which is the difference between a broken plugin and a true conflict.
What is Troubleshooting Mode, and how is it different from just deactivating plugins?
Troubleshooting Mode is a feature of the official Health Check and Troubleshooting plugin, and it is the single best tool for hunting a conflict because it does not take your site down for anyone. When you enable it, your own logged-in session gets a clean copy of WordPress with all plugins disabled and a default theme active, while every visitor and every other user still sees your normal live site with all plugins running. An admin-bar menu and a dashboard widget then let you toggle individual plugins on and off and switch the theme, just for you, so you can reactivate them one at a time and watch for the break in real time without a single visitor noticing. This is why you rarely need to deactivate plugins on the live front end at all, and it is the method we use to diagnose conflicts on production sites safely.
How do I deactivate plugins if I am locked out of wp-admin?
Do it at the file level over SFTP or your host file manager, which does not need the dashboard. To disable one specific plugin, open wp-content/plugins, find that plugin folder, and rename it, for example by adding -off to the end. WordPress can no longer find the plugin file, so it deactivates it automatically, and your site comes back if that plugin was the cause. To disable every plugin at once, rename the whole plugins folder itself, to something like plugins-hold. That deactivates all of them while preserving their settings, and once you can log in you rename it back and reactivate the plugins one at a time to find the offender. Neither method deletes anything or loses your plugin configuration.
What actually causes two plugins to conflict?
A conflict is two pieces of code colliding, and it happens in a handful of specific ways. The most severe is a PHP function-name collision: two plugins define a function with the same name without guarding it, so PHP throws a Cannot redeclare function fatal and the site white-screens. Another common one is a JavaScript conflict, where a plugin bundles its own copy of a library like jQuery instead of using the version WordPress already loads, which breaks the shortcut other scripts rely on. There are also hook and priority conflicts, where two plugins hook the same action or filter and one undoes the other or they run in the wrong order, and asset conflicts, where two plugins load clashing CSS or duplicate library versions. Less often, two plugins fight over the same database option. Each type has a specific fix, but they all surface through the same isolation process.
What is a "Cannot redeclare function" error?
It is the classic plugin-conflict fatal. PHP does not allow the same function name to be defined twice, so when two plugins, or a plugin and your theme, both declare a function with the same name, the second one triggers a Cannot redeclare function fatal error and the site goes to a white screen. It usually happens with common, generically named functions that a developer forgot to make unique. The correct developer fix is to wrap the declaration in a check, if the function does not already exist then define it, or to give the function a unique prefix. As the site owner, the immediate fix is to deactivate one of the two conflicting plugins, which we then help you replace with one that does not collide, so you keep the feature without the crash.
My plugin will not update, or the update fails partway. Why?
A failed plugin update is usually a file-permission problem, a memory or timeout limit, a connectivity issue reaching the update server, or, for a premium plugin, a license that is not connected so the update is refused. Start by confirming the site can write to wp-content and that your memory limit is adequate, then retry. For a premium plugin, check that its license is active and entered, because many premium plugins deliver updates only to licensed sites. If an update fails halfway and leaves the plugin broken, the clean fix is to deactivate it, delete the plugin files, and reinstall the current version fresh, which does not delete the plugin data stored in the database. We do this safely so a half-applied update does not leave the site in a broken state.
A plugin will not activate, with "the plugin could not be activated because it triggered a fatal error." What now?
That message means the plugin hit a PHP fatal error the moment it loaded, so WordPress refused to activate it and, helpfully, left the rest of your site running. The most common causes are a PHP version the plugin does not support, a missing dependency such as another plugin it requires, or a conflict with something already active. Enable the debug log and read the fatal it records on activation, which names the exact file and line. If it is a PHP version issue, the plugin needs an update to a compatible release, or your PHP version needs adjusting. If it is a missing dependency, install what it requires first. We read the log, identify which of these it is, and get the plugin running or find a working alternative.
Is it safe to deactivate plugins on a live site?
Deactivating a plugin is safe in the sense that it does not delete anything, your content and the plugin settings are preserved, but on a live site it can visibly disable a feature while it is off, so a contact form, a slider, or a payment method could stop working for visitors during the test. That is exactly why we use Troubleshooting Mode, which isolates plugins only for your own session so visitors never see a disabled feature. When Troubleshooting Mode is not an option, we do the deactivation testing during quiet traffic or on a staging copy, and we reactivate quickly. The one thing to avoid is deleting a plugin to test it, because deleting, unlike deactivating, can remove its data. Deactivate to test, never delete.
How many plugins is too many?
There is no magic number, and the common advice to just use fewer plugins misses the point. A well-coded plugin that you use adds little cost, while a single poorly-coded one can slow the whole site or start a conflict, so it is about quality and necessity, not the count. That said, every active plugin is more code that loads, more potential conflicts, and more to keep updated and secure, so it is worth removing plugins you no longer use, avoiding several plugins that each do a small thing one good plugin could do, and being wary of heavy page-builder and slider plugins that load a lot on every page. We audit what is actually installed, remove the dead weight, and flag the one or two plugins doing real damage, rather than applying an arbitrary limit.
Should I use a nulled or an abandoned plugin?
No to both, for security reasons. A nulled plugin, a paid plugin cracked and given away free, very frequently contains injected malware or a backdoor, and installing one is one of the most common ways sites get hacked, so it is never worth the saving. An abandoned plugin, one the author has stopped updating, is a slower risk: because most WordPress vulnerabilities are found in plugins, an unmaintained plugin that stops receiving security fixes becomes an open door over time as new flaws are discovered and never patched. Industry reporting consistently attributes the large majority of WordPress vulnerabilities to plugins, so keeping plugins updated and replacing abandoned ones is core security hygiene. We help you swap a risky plugin for a maintained equivalent without losing the feature.
Is a plugin problem the same as the WordPress white screen of death?
A plugin is the single most common cause of the white screen of death, but they are not the same thing. The white screen, a blank page or a critical error for every visitor, happens when PHP hits a fatal error, and a plugin fatal or a conflict between two plugins is the most frequent trigger, but a theme, a PHP version change, or a memory limit can cause it too. The way to tell is the isolation process on this page: if deactivating your plugins clears the white screen, a plugin was the cause and you are in the right place, and if it does not, our white screen page covers the other causes. This plugin page focuses on everything that is specifically the plugins, conflicts, updates, activation, and security.
Sources and further reading
The troubleshooting method and the Troubleshooting Mode behavior come from the official WordPress support handbook and plugin; the conflict mechanics from the WordPress developer resources.
- Make WordPress: Troubleshooting using the Health Check
- WordPress.org: Health Check and Troubleshooting plugin
- Learn WordPress: Troubleshooting plugin and theme conflicts
- WordPress Developer: Common WordPress errors
- WordPress Developer: JavaScript best practices and jQuery no-conflict
- WordPress Developer: wp_enqueue_script and dependencies