Table of Content
- Back up your site first
- Find your symptom in the table
- Turn on the error log and read it
- Get back in if you are locked out
- Test for a plugin conflict
- Plugin is active but nothing happens
- Clear every cache layer
- Check PHP version, memory, and limits
- Decide if the plugin is abandoned
- What to send the developer
- Stop it happening again
Most guides hand you one long list and tell you to work through it from the top. That wastes your time. The symptom you are seeing already points to the cause, so start there instead.
Covers activation failures, silent plugins, conflicts, and lockouts. Most fixes need no file access.
Back up your site first
Some of the steps below can break things further if you go in blind. Two minutes of prep saves you a bad afternoon.
DO THIS BEFORE ANYTHING ELSE Take a full backup of both your files and your database. If your host has one-click restore points, make one now and note the time. If you have a staging site, do all of this there first and copy the fix across once it works. Plugin conflicts often look fixed and then come back. |
You can reach almost every fix below without FTP. I have marked the few that need file access. If you are on managed hosting with no file access at all, you can still deactivate plugins from the database or ask support to rename one folder for you.
Find your symptom in the table
"Plugin not working" covers at least five different problems that have little in common. Find your row, go to that section, and skip the rest.
| What you are seeing | What it usually means | Go to |
|---|---|---|
| White screen or 500 error after activating | A fatal PHP error | Section 3, then 4 |
| Plugin will not activate at all | Your server does not meet its requirements | Section 8 |
| Plugin is active but its features never appear | It is failing quietly | Section 6 |
| It worked yesterday and broke after an update | A conflict with another plugin or theme | Section 5 |
| Settings save but the front end does not change | Caching | Section 7 |
| Shortcode prints as plain text on the page | Plugin is off or the shortcode is wrong | Section 6 |
| Works for you, broken for other users | A user role problem | Section 9 |
| Buttons do nothing, editor will not load | A JavaScript conflict | Section 5 |
Turn on the error log and read it
WordPress hides PHP errors by default, which is why you often get a blank white page with nothing to go on. Turning the log on usually gives you a sentence naming the exact file and line that broke.
Open wp-config.php and find the line that says /* That's all, stop editing! */. Just above it, add this:
|
Reload the page that was breaking, then open /wp-content/debug.log. The newest entries are at the bottom. A fatal error looks like this:
|
That one line tells you three things. The plugin is some-addon. It is calling a WooCommerce function. WooCommerce is either switched off or out of date. You now have a specific fix instead of a checklist.
What the common errors mean
| Error text | What to do |
|---|---|
| Call to undefined function | A plugin it depends on is switched off. Turn the parent plugin back on |
| Allowed memory size exhausted | Raise your memory limit. See section 8 |
| Cannot redeclare function | Two plugins use the same function name. One of them has to go |
| Syntax error, unexpected | The plugin files uploaded badly. Delete it and install a fresh copy |
| Class not found | An update finished halfway. Reinstall the plugin |
TURN THIS BACK OFF WHEN YOU ARE DONE Leaving WP_DEBUG on for a live site is a security risk, and the log file grows with no limit. Set it back to false and delete the log file once you have your answer. |
Get back in if you are locked out
When a plugin causes a fatal error, you often cannot reach the dashboard to switch it off. That feels like a dead end but it is not. You can deactivate plugins without logging in.
CHECK YOUR EMAIL FIRST Since WordPress 5.2, a fatal error sends an email to your admin address with a recovery link. That link logs you in with the broken plugin paused. Check that inbox before touching any files. If your site cannot send email, which is common, it will not arrive and you use the methods below. |
METHOD 1 Rename the plugin folder Connect by FTP or open your host file manager and go to /wp-content/plugins/. Find the folder for the plugin you last touched and rename it, for example woocommerce to woocommerce-off. WordPress checks that folder on every page load. When it cannot find it, it switches that plugin off by itself and your dashboard comes back. Rename it back once you have a fix, and it stays off until you turn it on manually. |
METHOD 2 Switch off every plugin at once If you do not know which plugin broke it, rename the whole plugins folder to plugins-off. Every plugin switches off and you get back in. Then rename it back to plugins. All your plugins stay off but keep their settings, so you can turn them back on one at a time and find the one causing trouble. |
METHOD 3 Switch them off from the database If you have no file access but you do have phpMyAdmin, open the wp_options table and find the row where option_name is active_plugins. Copy the current value somewhere safe first. Then change the value to a:0:{} and every plugin switches off. Your table prefix may not be wp_. Check wp-config.php for the real one. |
Test for a plugin conflict
If the plugin worked and then stopped, or it works on one site but not another, a conflict is the likely cause. This test always gives you an answer.
Step 1: Rule out your theme
Switch to a default theme, one of the Twenty-something ones. If the plugin starts working, your theme is the problem and the theme developer is who you need.
Step 2: Switch off every other plugin
Leave only the broken plugin on. If it still fails with everything else off and a default theme, the plugin itself is broken or your server does not meet its requirements. Go to section 8.
Step 3: Turn them back on in halves
This is where most guides waste your afternoon. With 20 plugins, turning them on one at a time means up to 20 reloads. Doing it in halves takes about five.
Turn on half your plugins and test. If the problem comes back, the cause is in that half, so switch off half of that group and test again. If the problem stays away, it is in the other half. Keep splitting the group you suspect. Twenty plugins takes around five rounds and a hundred takes about seven.
USE THE HEALTH CHECK PLUGIN Switching plugins off on a live site takes down caching, security, and checkout while you work. Health Check and Troubleshooting is an official plugin that runs this whole test in a mode only you can see, so your visitors keep seeing the working site the entire time. |
If it is a JavaScript conflict
This looks different from a PHP error. The page loads fine but buttons do nothing, tabs will not switch, the editor will not open, or a slider sits frozen. Nothing shows up in your error log because the problem is in the browser, not on the server.
Press F12 to open your browser console and reload the page. Look at the Console tab for errors in red. Something like Uncaught TypeError: $ is not a function points to a jQuery conflict. The file path in the error tells you which plugin caused it.
Also check whether your caching plugin has minify or combine JavaScript switched on. Turn that off and test again. Combining scripts breaks plugins often enough to be worth ruling out early.
Plugin is active but nothing happens
No errors, no white screen, the plugin sits there marked active, and none of its features exist. This one is frustrating because there is nothing to read. Work through these in order.
• Check if it needs setting up. Plenty of plugins do nothing until you enter an API key, pick a page, or switch something on. Look under Settings, Tools, or its own menu item. A lot of "broken plugin" reports are just plugins nobody configured.
• Check the plugin it depends on. Add-ons need their parent plugin running. A WooCommerce extension does nothing without WooCommerce, and many will switch on quietly rather than warning you.
• Check where it is meant to appear. Some plugins only work on certain post types, only for logged-in visitors, or only where you place a shortcode or block. Read the plugin documentation before deciding it is broken.
• If a shortcode shows as plain text like [my_plugin_form], the plugin is off, the shortcode name is misspelled, or you pasted it somewhere that does not run shortcodes, such as some page builder text widgets.
• Check the log anyway. Turn on the error log from section 3. Warnings that do not break the page still get written down, and they often explain why a feature never showed up.
Clear every cache layer
Caching has a clear signature: the change works in your dashboard, sometimes works in a private window, and refuses to show up on the live page. If that sounds familiar, clear your caches before debugging anything else.
There are usually more layers than people expect, and clearing only one gives you a false result.
| Layer | Where to clear it |
|---|---|
| Caching plugin | WP Rocket, W3 Total Cache, LiteSpeed and similar all have a purge all button |
| Host cache | Kinsta, WP Engine and SiteGround run their own caching with a separate purge button |
| CDN | Cloudflare and similar cache copies closer to your visitors, so purge there too |
| Object cache | Redis or Memcached, if your host runs it, holds database results |
| Your browser | Hard reload, or test in a private window |
| OPcache | A PHP level cache that can hold old plugin code after an update. Ask your host to clear it |
THE FIFTEEN SECOND CHECK Open the page in a private window on a different device, ideally on mobile data rather than your own wifi. If it looks right there but wrong for you, the problem is caching and not the plugin. |
Check PHP version, memory, and limits
When a plugin refuses to switch on or dies partway through a job, the cause is often your server setup rather than a bug in the plugin. Check the real numbers instead of guessing.
Go to Tools > Site Health > Info. That screen shows your PHP version, memory limit, max execution time and upload size, with no file access needed. Compare those to what the plugin lists on its WordPress.org page.
| Problem | What you see | How to fix it |
|---|---|---|
| PHP too old | Plugin will not switch on, or an error mentions an unexpected character | Update PHP in your hosting panel. Test on staging first, since old themes can break |
| PHP too new | Deprecation warnings fill the log, an older plugin stops after a host upgrade | Update the plugin, or move PHP back one version while you find a replacement |
| Memory limit | Memory exhausted errors, white screen on heavy pages, imports fail partway | Add define( 'WP_MEMORY_LIMIT', '256M' ); to wp-config.php, or ask your host |
| Execution time | Long jobs like imports or backups stop silently near 30 seconds | Raise max execution time in your hosting PHP settings |
| Upload size | Cannot upload the plugin zip file, or big forms fail to send | Raise upload max filesize and post max size together |
| Missing extension | Plugin asks for something like curl, gd, mbstring or zip | Ask your host to switch it on. This is usually a quick support ticket |
If adding WP_MEMORY_LIMIT changes nothing, your host is capping memory above WordPress and only they can raise it. That is a support ticket, not a config change.
Fix problems that only affect some users
This one is narrow but confusing. The plugin works perfectly for you as an administrator, and an editor or shop manager says it is missing or broken. Nothing is wrong with the plugin. It is showing its features only to roles with a permission those users do not have.
Ask the affected person which role they have, then check whether the plugin has a setting for minimum role. Many do. If it does not, a role editor plugin can grant the exact permission the plugin looks for, though check what else that permission unlocks before you hand it out.
The same thing happens on multisite. A plugin may need network activation, or it may be switched on network wide when it should be per site. Check which it is before digging further.
Decide if the plugin is abandoned
Sometimes there is no fix on your side. Check the plugin page on WordPress.org for these signs.
• Not updated in over a year. WordPress.org shows a warning when a plugin has not been tested with recent versions. Treat that as a real risk.
• A support forum full of the same unanswered question. If people reported your exact problem months ago and nobody replied, waiting will not help.
• Closed or removed from the directory. This sometimes follows a security problem. If a plugin was pulled, remove it rather than keep running it.
• Recent reviews describing your problem after one specific update. That points to a bug the developer introduced, and going back a version is a fair temporary fix.
To go back a version, open the Advanced View section on the plugin WordPress.org page, which lists older releases. Switch off and delete the current version, then upload the older zip file. Turn off auto updates for that plugin afterwards or it will update straight back into the broken version.
GOING BACK A VERSION IS TEMPORARY An old version stops getting security fixes. Use it to get your site working again, then plan the real move, either to a plugin that is still maintained or to a version where the bug is fixed. Do not leave an old plugin pinned for months and forget about it. |
What to send the developer
If you end up on a support forum or a paid support desk, what you put in your first message decides whether this takes one reply or six. Include all of this.
1. The exact error text from your log or browser console, pasted as text rather than described or screenshotted
2. Your WordPress version, PHP version and plugin version, all from Site Health > Info
3. Your active theme, and whether the problem still happens on a default theme
4. Whether it still happens with every other plugin switched off, since this is the first thing they will ask
5. The steps to reproduce it, meaning what you clicked and what happened instead
6. When it started and what changed just before, such as an update, a host move, or a PHP version change
That last point matters more than people expect. "It broke after I updated WooCommerce on Tuesday" tells a developer more than three paragraphs describing the symptom.
Stop it happening again
Most plugin failures come from a few avoidable habits rather than bad luck.
• Test updates on staging. Auto updating everything means your visitors find the breakages before you do. A staging site that matches production catches most of them first.
• Update a few at a time. Updating fifteen plugins at once and then finding the site broken leaves you fifteen suspects. Three at a time leaves you three.
• Delete plugins you do not use. Every plugin is another chance of a conflict and another developer you depend on. Switching one off is not enough, because the code still sits on your server. Delete it.
• Read the changelog before big updates. Developers usually flag breaking changes and new requirements there. Thirty seconds of reading prevents the case where a plugin suddenly needs PHP 8.1 and your host runs 7.4.
• Test your backups. A backup you have never restored is a guess. Restore one to staging once so you know it works and how long it takes.
The short version Turn on the error log and read it before you do anything else. That one step solves most cases, because a named file and line beats guesswork. If there is no error to read, test for a conflict by halves rather than one plugin at a time, and use Health Check and Troubleshooting so your visitors never see the site with its plugins off. If the plugin has not been updated in years and the forum is full of your problem with no replies, stop. You are not fixing that one, and your time is better spent moving to something maintained. |
Post Comment
Share your thoughts about this article.
Be the first to post a comment!
