Why WordPress Plugins Stop Working
Before jumping to fixes, it helps to understand what actually causes plugin failures. The most common reasons are:
- Plugin conflict — two or more plugins trying to do the same thing, or one plugin breaking another's functionality
- Theme conflict — a theme (especially page builders) that interferes with how a plugin loads its scripts or styles
- WordPress core update — a new version of WordPress that deprecated a function the plugin relied on
- PHP version mismatch — your host updated PHP and the plugin isn't compatible with the new version
- Corrupted plugin files — a failed or incomplete update that left broken files on the server
- Caching — your site cache is serving a version of the page before the plugin was active or after it broke
- Memory limit — WordPress ran out of memory mid-execution and the plugin never fully loaded
Step 1 — Check the Basics First
Before assuming a conflict, rule out the obvious:
- Hard refresh the page (Ctrl+Shift+R or Cmd+Shift+R) to bypass browser cache
- Clear your site cache if you're using a caching plugin (WP Rocket, W3 Total Cache, LiteSpeed, etc.)
- Confirm the plugin is actually activated in Plugins → Installed Plugins
- Check if the plugin requires a license key that has expired or deactivated
Step 2 — Check for a Recent Change
The best clue is usually timing. Ask yourself: what changed right before the plugin stopped working?
- Did WordPress just update automatically?
- Did you or your host update PHP?
- Did you install or update another plugin around the same time?
- Did you switch or update your theme?
If you can pinpoint the change, you've likely found the cause. Roll it back or deactivate the suspected component first.
Step 3 — Isolate the Conflict
If you can't identify the cause from timing, use the classic isolation method:
- Deactivate all plugins except the one that's broken
- Test if the problem plugin now works
- If yes — reactivate your other plugins one at a time, testing after each one
- When the problem returns, you've found the conflicting plugin
- If the problem plugin still doesn't work with everything else deactivated — switch to a default WordPress theme (Twenty Twenty-Four) and test again
This process is systematic and almost always identifies the root cause within a few minutes.
Step 4 — Reinstall the Plugin
If isolation didn't reveal a conflict and the plugin was recently updated, the update itself may have been corrupted. To reinstall cleanly:
- Deactivate and delete the plugin (your settings are usually preserved in the database)
- Re-download the plugin from WordPress.org or your account page
- Upload and reinstall via Plugins → Add New → Upload Plugin
- Reactivate and test
Step 5 — Check PHP Compatibility
If your host recently updated PHP (or if you're on a newer PHP version), the plugin may not support it. Check the plugin's page on WordPress.org for its tested PHP version range. If your PHP version exceeds what the plugin supports, you have two options:
- Contact the plugin developer — many will release a compatibility update quickly once aware
- Temporarily downgrade PHP if your host allows it — but treat this as a short-term fix only
Step 6 — Check for JavaScript Errors
Plugins that add admin functionality or front-end widgets often break silently due to JavaScript conflicts. Open your browser's developer tools (F12), navigate to the Console tab, and reload the page. Look for red errors — they'll often name the conflicting script and which plugin or theme it belongs to.
Step 7 — Check the Error Log
If you have access to your server's error log (via your host's file manager or cPanel), check wp-content/debug.log after enabling WordPress debug mode. Add these lines to your wp-config.php temporarily:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Reload the broken page, then check the log file. PHP fatal errors and warnings will point directly at the problem.
When to Stop Troubleshooting and Get Help
If you've worked through all the steps above and the plugin still isn't working, the issue may be a deeper server configuration problem, a database issue, or a plugin that's simply broken and needs a developer-level fix. At that point, trying more things without expertise can make the problem worse — especially if the plugin is handling payments, memberships, or other critical functionality.
CriticalWP's emergency support handles exactly these situations — systematic diagnosis, root cause identification, and a proper fix rather than a temporary workaround.
How to Prevent Plugin Issues Going Forward
- Never update all plugins at once — update one at a time and test after each
- Use a staging environment for plugin updates before applying to production
- Keep backups that you can actually restore — and test restores periodically
- Audit your plugin list — every inactive plugin is a liability. Delete what you don't use
- Check plugin age and update frequency before installing — a plugin not updated in 2+ years is a risk
Plugin Conflict Decision Tree
Not sure where to start? Work through this in order — most plugin issues resolve at step 2 or 3.
- Did it break after a specific change? — Update, new plugin install, hosting change, PHP upgrade. If yes, revert or deactivate that change first.
- Does the problem disappear in a default theme? — Switch to Twenty Twenty-Four. If it resolves, the issue is a theme conflict, not the plugin.
- Does it disappear with all other plugins deactivated? — If yes, reactivate one at a time to find the conflict. If no, the issue is the plugin itself.
- Is the plugin up to date? — Outdated plugins frequently break on newer WordPress/PHP versions. Update and test.
- Does a clean reinstall fix it? — Delete and reinstall fresh from the source. Corrupted update files are common.
- Does the error log name a specific file? — Enable WP_DEBUG, reproduce the error, check
wp-content/debug.log. The file path in the error points directly at the problem. - Is your PHP version compatible? — Check the plugin's WordPress.org page for tested PHP versions. If your host updated PHP, this is often the culprit.
Most Commonly Conflicting WordPress Plugins
Some plugins conflict with each other by design — they try to do the same thing, hook into the same WordPress filters, or load competing JavaScript libraries. These are the most common combinations that cause issues:
- Multiple caching plugins — WP Rocket + W3 Total Cache + LiteSpeed Cache running simultaneously. Only ever run one caching plugin.
- Multiple SEO plugins — Yoast + Rank Math + All in One SEO. They write duplicate meta tags and fight over the same hooks. One only.
- Page builders + optimization plugins — Elementor with Autoptimize or similar CSS/JS minifiers. Minifiers often break Elementor's generated CSS. Use Elementor's built-in asset loading settings instead.
- Security plugins + caching plugins — Wordfence + WP Rocket can conflict on firewall rules that intercept cached page delivery.
- Multiple form plugins — Gravity Forms + Contact Form 7 + WPForms all loading their scripts on every page causes performance issues and occasional JS conflicts.
- WooCommerce + poorly coded third-party extensions — WooCommerce has a strict hook structure. Extensions that don't follow it correctly break checkout, cart, or product pages.
- ACF + plugins that modify post meta — Plugins that aggressively clean or modify
wp_postmetacan corrupt ACF field data. See our ACF complete guide for details.
PHP Version Compatibility — What Breaks What
PHP version mismatches are the #1 cause of sudden plugin failures after a hosting change or server update. Here's the current landscape:
- PHP 8.2–8.3 — Current recommended versions. Most actively maintained plugins support this. Older plugins (last updated 2020 or earlier) frequently break on PHP 8.x due to deprecated functions.
- PHP 8.0–8.1 — Still widely supported. If a plugin breaks on 8.2, downgrading to 8.1 temporarily is a valid short-term fix while you wait for an update.
- PHP 7.4 — End of life. Some hosts still offer it. Plugins coded for 7.4 may fail silently on 8.x — no error, just broken functionality.
- PHP 7.3 and below — Do not use. Security vulnerabilities exist and plugin compatibility is unreliable.
To check your current PHP version: go to Tools → Site Health → Info → Server in your WordPress admin. Cross-reference against the plugin's tested PHP version on its WordPress.org page.
How to Read WordPress Debug Logs
Once WP_DEBUG is enabled (see Step 7 above), your wp-content/debug.log will contain entries like this:
[08-May-2026 14:22:31 UTC] PHP Fatal error: Uncaught Error: Call to undefined function
some_deprecated_function() in /wp-content/plugins/plugin-name/includes/class-main.php:247
Reading this: the plugin plugin-name is calling a function some_deprecated_function() that no longer exists — almost always a PHP version incompatibility. The line number (247) tells you exactly where in the plugin's code the failure occurs.
Common error patterns and what they mean:
- Call to undefined function — PHP version mismatch. The function was removed in a newer PHP version.
- Cannot redeclare function — Two plugins defining the same function name. A namespace collision — usually a poorly coded plugin.
- Maximum execution time exceeded — Plugin is running too long. Often a database query problem or an infinite loop in the plugin's code.
- Allowed memory size exhausted — Plugin is consuming too much memory. Increase WP memory limit or identify which plugin is the cause.
- Call to a member function on null — Plugin expected an object but got nothing. Usually a missing dependency or incorrect initialization order.
Plugin Issues Specific to Managed WordPress Hosting
If your site is on a managed WordPress host — WP Engine, Kinsta, Cloudways, or CriticalWP — some plugin issues are specific to the managed environment:
- Prohibited plugins — WP Engine and some other managed hosts prohibit specific plugins (primarily caching plugins) that conflict with their server-level caching. If a plugin was working on shared hosting and breaks on managed hosting, check your host's prohibited plugin list.
- Object caching conflicts — Managed hosts often run Redis or Memcached at the server level. Plugins that implement their own object caching (some security plugins, some performance plugins) conflict with this.
- File system restrictions — Managed hosts restrict write access to certain directories. Plugins that write files outside
wp-content/will fail silently. - Staging environment plugin state — Plugins activated on staging that aren't activated on production (or vice versa) cause environment-specific failures that are confusing to diagnose.
On CriticalWP's managed platform, plugin updates are handled by our team — tested before deployment so you're not discovering conflicts after the fact. See what's included →
When a Plugin Simply Cannot Be Fixed
Sometimes a plugin is broken at the code level — an incompatible update with no fix yet, an abandoned plugin with no maintainer, or a fundamental conflict with your theme or stack that has no workaround. Signs you're in this situation:
- The plugin hasn't been updated in 12+ months and shows compatibility warnings on WordPress.org
- The plugin's support forum shows many open, unresolved reports of the same issue
- The conflict persists even in a default theme with all other plugins deactivated
- The developer has closed the plugin or marked it as no longer maintained
In this case, find an actively maintained alternative. WordPress.org lists plugins sorted by last update date — filter by plugins updated within the last 6 months and look for alternatives with 4.5+ star ratings and 10,000+ active installations.
On a CriticalWP managed plan, plugin updates are handled by our team — tested before deployment so you're not the one discovering a conflict after the fact.