You updated a plugin last night and now something’s broken. Or you installed a new one and the site went white. Or, worst of all, the plugin still shows as active but has completely stopped doing anything. None of these have the same fix, and that’s exactly the problem with most troubleshooting guides: they treat “plugin not working” as one thing when it’s really about six different things.
This guide diagnoses by symptom first. Find what you’re seeing in the table below and jump straight to the fix that applies. Most of these take under 15 minutes once you know what you’re actually dealing with.
Quick answer
Clear your cache first. Seriously. About a third of all “plugin not working” reports get resolved by a full cache clear before anything else gets touched. If that doesn’t fix it, the second most common cause is a conflict with another plugin, and there’s a free official WordPress tool that isolates it safely without affecting live visitors.
Before You Touch Anything
Two minutes of documentation now saves an hour of confusion later. The people who get stuck longest are usually the ones who started clicking things immediately and lost track of what was active before they started.
✓ Screenshot your active plugin list before deactivating anything. Plugins → Installed Plugins. You’ll reference it multiple times.
✓ Write down what changed last. A plugin update? A new install? A WordPress core update? A PHP version change your host applied automatically without telling you? That last one happens more than people realize.
✓ Take a backup right now, before anything else. UpdraftPlus or your host’s built-in tool. Skipping this turns a fixable problem into a potentially unfixable one if something goes wrong mid-troubleshoot.
✓ Open browser DevTools (F12, then Console tab) and check for red errors. They often name the exact plugin causing the problem before you’ve touched a single setting.
Diagnose Your Symptom First
Find your specific symptom below. Each one points to a different cause and a different fix. Working through steps in the wrong order for your situation wastes time.
| What you’re seeing |
Most likely cause |
Where to start |
| White screen, blank page |
PHP fatal error or memory limit hit |
Steps 4 and 5, then enable WP_DEBUG |
| “There has been a critical error” |
Plugin conflict or PHP version mismatch |
Steps 3 and 4 |
| Plugin menu item has disappeared |
Plugin deactivated itself or files got corrupted |
Step 6 (clean reinstall) |
| Feature stopped working, no error shown |
Cache serving broken version, or REST API blocked |
Step 1 (cache clear), then Advanced section |
| Broke after an update |
Conflict with another plugin or WP core version |
Steps 2 and 3 |
| Locked out of wp-admin |
Security plugin or PHP error on the login page |
Locked Out section below |
The Six Real Causes of WordPress Plugin Failures
Knowing what you’re dealing with before starting saves you from applying the wrong fix. These are the six causes that account for the vast majority of plugin failures in the wild.
Plugin or theme conflict
By far the most common. Two plugins hooking into the same WordPress action or filter end up fighting over it. It happens a lot after installing something new, or after updating a plugin that changed how it hooks into things. Themes can cause it too, usually when they use older WordPress functions that a newer plugin doesn’t expect to encounter. The fix is conflict isolation, covered in Step 3.
PHP version mismatch
Modern plugins need PHP 8.1 minimum. Many now require PHP 8.2. Sites still running PHP 7.4 will see silent failures, deprecated function warnings, or hard crashes with no useful error at all. Worth checking in your hosting panel before spending time on anything else. Most hosts let you switch PHP versions in one click and it takes effect instantly.
Cache serving a stale broken version
This one catches people off guard regularly. The plugin is actually working fine. But the site is still serving a cached version from before the fix. Here’s what most people miss: there are up to four independent caches that all need clearing. Browser cache. Your WordPress caching plugin (WP Rocket, LiteSpeed Cache, W3 Total Cache). Your CDN (Cloudflare, Bunny.net). And your server’s object cache if your host uses Redis or Memcached. Clearing just one isn’t always enough.
Corrupted plugin files
A dropped connection during an update, a server timeout, or a failed auto-update can leave the plugin’s files in a half-written state. It shows as active in the dashboard but behaves erratically. Clean reinstall from a fresh download sorts this out quickly.
Memory limit too low
WordPress defaults to 40MB. Many shared hosts cap it at 64MB or 128MB. WooCommerce needs 256MB minimum to run reliably. Elementor needs similar. When the limit gets hit, you get white screens or partial loads with no clear error. This is fixable directly in wp-config.php without calling your host, and the specific code to add is in Step 5 below.
REST API blocked
This one gets missed constantly. The Block Editor, WooCommerce, Contact Form 7, and most modern JavaScript-heavy plugins all rely on WordPress’s REST API. If a security plugin or a server firewall blocks requests to /wp-json/, those plugins appear completely broken even though nothing is actually wrong with them. You can test this immediately by visiting yoursite.com/wp-json/ in a browser. Should return JSON. If it returns an error page instead, that’s your cause.
Fixes in the Right Order
1Clear every cache layer
Start here, always. Hard-refresh the browser first (Ctrl+Shift+R on Windows, Cmd+Shift+R on Mac). Then open your caching plugin and hit Purge All. Then flush the CDN cache from Cloudflare or wherever it’s configured. If your host uses Redis or Memcached, clear object cache too. SiteGround’s Dynamic Cache and Kinsta’s object cache both need to be purged separately from your WordPress caching plugin. This one step fixes more plugin reports than anything else on this list.
2Use the Health Check and Troubleshooting plugin
Install the Health Check and Troubleshooting plugin from WordPress.org. It’s free and official. What it does is activate a Troubleshooting Mode that disables all plugins and switches to a default theme, but only for your browser session. Your live site looks completely normal to visitors while you’re troubleshooting. You then reactivate plugins one at a time inside Troubleshooting Mode until the issue comes back. That’s the one causing it. This is dramatically safer than deactivating plugins directly on a live site.
3Manual conflict isolation if needed
Can’t install the Health Check plugin? Go to Plugins, select all active plugins, and bulk deactivate. Test the site. If the issue clears, reactivate them one by one and test after each. When the problem returns, you’ve found it. One thing worth knowing: save security plugins and caching plugins for last when reactivating. They hook into almost everything else and are the most likely to expose conflicts with other plugins.
4Check and update your PHP version
Log into your hosting panel and check the PHP version. You want PHP 8.1 minimum in 2026, with PHP 8.2 preferred for any site running current plugins. PHP 7.4 is end of life and will produce compatibility failures that don’t always show a useful error message. Most major hosts (SiteGround, Kinsta, WP Engine, Hostinger) let you switch with one click and the change takes effect on the next page load. The official PHP supported versions page shows what’s still receiving security patches.
5Fix the memory limit in wp-config.php
Open wp-config.php in File Manager or via FTP. Add these two lines immediately before the “That’s all, stop editing!” comment line:
wp-config.php — memory limit fix
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );
WP_MEMORY_LIMIT covers frontend and general WordPress operations. WP_MAX_MEMORY_LIMIT handles admin-side tasks like running bulk updates. 256M frontend and 512M admin covers WooCommerce, Elementor, and most other heavy plugins without needing to call your host.
6Reinstall the plugin cleanly
Deactivate the plugin. Note your settings, because they may not survive a full delete-and-reinstall. Delete it. Download a fresh copy directly from WordPress.org or the developer’s website. Reinstall from the fresh download. This resolves corrupted or partial files left behind by a failed update. One hard rule: never install nulled or cracked plugins. They’re among the most reliable malware delivery mechanisms in the WordPress ecosystem.
7Enable WP_DEBUG to find the exact error
If nothing above worked, turn on error logging. Add these three lines to wp-config.php before the stop-editing line, reproduce the problem, then check wp-content/debug.log for the specific error. It usually names the exact file and function. Turn these off once you’ve found the issue, since leaving debug mode active on a live site exposes error details to anyone visiting. The official WordPress debugging documentation covers additional constants and log management if you need to go deeper.
wp-config.php — debug logging
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Locked Out of wp-admin Entirely
When the broken plugin is on the login page or admin area itself, you can’t fix it from inside WordPress. You still have two reliable ways in without needing a developer.
Via File Manager (quickest option)
Log into your hosting panel and open File Manager. Navigate to public_html/wp-content/plugins/. Find the folder for the suspect plugin and rename it by adding “-disabled” at the end. WordPress automatically deactivates any plugin whose folder it can’t find. Refresh the site and try logging in. Once you’re in, rename it back or delete and reinstall cleanly.
Not sure which plugin is causing it? Rename the entire plugins folder to plugins-off. That deactivates everything at once. Log in, rename it back to plugins, then reactivate individually from inside the dashboard until you find the problem.
Via FTP
Connect with FileZilla or Cyberduck using the SFTP credentials from your host. Same process: navigate to /wp-content/plugins/ and rename the problem folder. Takes effect immediately on the next page load.
Advanced Causes Most Guides Miss
REST API blocked by a security plugin or server firewall
The Block Editor, WooCommerce, Contact Form 7, and almost every plugin using JavaScript heavily all depend on the WordPress REST API. A security plugin like Wordfence or iThemes Security blocking /wp-json/ requests makes those plugins look completely broken even when their files are fine. Test it by visiting yoursite.com/wp-json/wp/v2/ in a browser. You should see JSON. An error page means the REST API is blocked, and that’s your problem right there.
Must-use plugins (mu-plugins folder)
Most people don’t know this folder exists. WordPress has a wp-content/mu-plugins/ directory where plugins load automatically on every page, can’t be deactivated from the dashboard, and don’t appear in the regular Plugins list. Managed hosts like WP Engine, Kinsta, and Pantheon put their own code here. If you’ve worked through every conflict isolation step and still can’t find the cause, check this folder via File Manager or FTP. Anything in there is running whether you see it or not.
Auto-update silent failures
Since WordPress 5.5, plugins can auto-update in the background. A plugin can silently update to a broken version overnight and the first sign is user complaints at 7am. Check Dashboard → Updates for recent plugin version changes. If auto-updates keep causing problems, you can disable them per-plugin by adding add_filter( 'auto_update_plugin', '__return_false' ); to a functionality plugin, then manage updates manually on a schedule you control.
Stale transients in the database
Some plugins cache their own data in WordPress transients. When that data goes stale or gets corrupted, the plugin produces wrong results even though the code itself is fine. Install Transients Manager (free), delete all expired transients, and retest. This solves a specific class of “plugin appears active but results are wrong” failures that nothing else touches.
Block Editor-specific plugin failures
If a plugin adds blocks that aren’t appearing in the editor, check three things in this order: visit yoursite.com/wp-json/ to confirm the REST API is working, open the browser console (F12) with the editor open and look for JavaScript errors (they almost always name the source plugin), and verify the plugin supports your current WordPress version in its changelog. Those three cover 95% of Block Editor plugin failures.
Prevention Habits Worth Keeping
Sites that rarely have plugin problems aren’t running better software. They’re following a few consistent habits that the sites constantly firefighting aren’t.
| Habit |
Why it matters |
| Update 3 to 4 plugins at a time, not all at once |
Pinpoints which update caused a problem instead of guessing among 20 |
| Test updates on staging before pushing live |
Catches most conflicts before your users ever see them |
| Back up before every update, without exception |
Turns a potential disaster into a 10-minute restore |
| Avoid plugins not updated in over 12 months |
Old plugins break on new PHP and WordPress versions without warning |
| Delete inactive plugins, don’t just deactivate |
Deactivated plugins with security vulnerabilities still exist on the server |
Frequently Asked Questions
Why is my WordPress plugin not working after an update?
Almost always a conflict with another plugin or theme that wasn’t compatible with the new version. Use the Health Check and Troubleshooting plugin to disable everything without affecting live visitors, then reactivate one at a time until the issue comes back. That’s the one causing it. Going forward, update in batches of 3 or 4 rather than all at once so you can actually tell which update caused a problem.
How do I troubleshoot a plugin without breaking the live site?
The Health Check and Troubleshooting plugin (free, from WordPress.org) is built exactly for this. Its Troubleshooting Mode disables all plugins and switches to a default theme only for your browser session. Visitors see nothing different. You work through the plugins one at a time on your end until you find the one causing the issue.
What PHP version do WordPress plugins need in 2026?
PHP 8.1 minimum, with PHP 8.2 preferred. PHP 7.4 is officially end of life and causes compatibility failures that don’t always produce a clear error. Check your version in cPanel or your host’s dashboard and upgrade if needed. SiteGround, Kinsta, WP Engine, and Hostinger all let you switch PHP versions instantly from the control panel.
How do I disable a plugin when locked out of wp-admin?
Go to your hosting control panel and open File Manager. Navigate to public_html/wp-content/plugins/ and rename the suspect plugin’s folder. Adding “-disabled” to the folder name works fine. WordPress deactivates it automatically. Don’t know which plugin it is? Rename the entire plugins folder to plugins-off. That kills everything at once. You can log back in and reactivate selectively from there.
Plugin shows active but does nothing. What’s going on?
Three things to check. First, clear every cache layer including browser, WordPress plugin, CDN, and object cache. Second, test the REST API by visiting yoursite.com/wp-json/ in a browser (should return JSON, not an error page). Third, install Transients Manager and delete all expired transients. Stale transient data can make a plugin appear to do nothing even when it’s technically active and working.
Can a WordPress core update break plugins?
Yes. Major WordPress version updates especially. Plugin developers usually release compatibility patches within a few days, but you need to install them. The order matters: update WordPress core first, then plugins, then themes. If the site is important, run updates on staging before applying to live. And never bulk update everything at once without a recent backup you can restore quickly.
What memory limit do plugins need to run properly?
WordPress starts at 40MB. Most shared hosts set it between 64MB and 128MB.
WooCommerce officially recommends 256MB minimum, and Elementor needs roughly the same. Add
define( 'WP_MEMORY_LIMIT', '256M' ); to wp-config.php before the stop-editing line. That’s usually enough for most plugin combinations without any hosting configuration change.
Most Plugin Problems Have a 15-Minute Fix
Match your symptom in the table above, clear your cache before touching anything else, and use the Health Check and Troubleshooting plugin to isolate conflicts without touching the live site. Those three steps handle the majority of plugin failures without any developer involvement.
If you’ve worked through all of this and the problem is still there, it’s usually something deeper than standard troubleshooting reaches. A developer who knows WordPress internals can typically resolve it in under an hour, often faster than a second afternoon of solo debugging.
Running WooCommerce? See our
WooCommerce product SEO guide for the store-specific SEO issues most site owners don’t know they have, including the duplicate content and faceted navigation problems WooCommerce creates by default.
BUSINESS9 months ago
HEALTH AND FITNESS9 months ago
Uncategorized9 months ago
Education9 months ago