How to test if a WordPress plugin is actually active and working
Before you debug the feature, prove the plugin is active. This is the step most people skip, and it costs them hours they don’t have.
Here’s how it usually goes. Something on your site stops working. A form isn’t sending. A payment gateway isn’t processing. A custom field that should appear in your admin panel isn’t there. You spend an hour adjusting settings, clearing cache, reading documentation. You ask your AI assistant. It suggests three things to try. You try them. Nothing changes. Then, somewhere around hour two, you find out the plugin responsible for the feature was never active in the first place. It looked active. The settings page was there. But it wasn’t running.
That hour is gone. And the frustrating part is that this failure mode shows up constantly, in slightly different forms, across almost every category of WordPress problem.
Why “active” doesn’t always mean “working”
WordPress has two different states that people often conflate: a plugin can be activated in the dashboard and still not be executing correctly. The activation checkbox tells you the plugin is registered in WordPress’s option table. It doesn’t tell you whether the plugin’s code is actually running when it should, whether its dependencies are present, whether it’s conflicting with something else and silently failing, or whether a recent update broke it in a way that produces no visible error.
The WordPress admin panel shows you what’s supposed to be happening. Your debug log shows you what’s actually happening. Those two things are not always the same.
Step one: confirm the plugin shows as active
Start in Plugins > Installed Plugins. An active plugin has a blue-tinted row and a “Deactivate” link. An inactive plugin has an “Activate” link. This sounds obvious, but it’s worth checking explicitly before anything else, because plugins can be deactivated automatically when WordPress detects a fatal error on activation, and you won’t always receive a visible notification that this happened.
If the plugin isn’t there at all, that’s a different problem: it may not have been installed, or the install failed partway through. Either way, you’ve found the issue in thirty seconds rather than two hours.
Step two: check whether the plugin is actually loading
A plugin can show as active and still not load. This happens when there’s a PHP fatal error in the plugin code, a missing dependency, or a conflict with another plugin that prevents it from initializing. WordPress’s default behavior is to deactivate the plugin silently when this occurs, but not always. Sometimes the plugin stays in the active list and simply fails to run.
To find out, you need your debug log on. If you haven’t set that up yet, here’s how to enable the WordPress debug log and what to do with what you find. Once it’s on, reproduce the action that should trigger the plugin, then open wp-content/debug.log and look for errors that reference the plugin’s folder name or file name. A PHP error on load will appear there, and it will tell you exactly what went wrong and on which line.
If the debug log is clean and the plugin isn’t producing the expected behavior, that’s the next question: is the plugin running at the right moment?
Step three: test the specific hook or feature
WordPress plugins work by attaching functions to hooks. A hook is a point in the WordPress execution sequence where the plugin registers that it wants to do something. If the hook fires but the plugin’s function isn’t attached to it — because the plugin didn’t load, or attached at the wrong priority, or was unhooked by something else — the feature doesn’t run and nothing in the interface tells you why.
For most non-technical site owners, the practical version of this test is: can you trigger the plugin’s most basic visible output? If it’s a form plugin, does a new form render on a test page? If it’s a payment gateway, does it appear as an option at checkout, not just in settings? If it’s a caching plugin, does a cached version of a test page actually exist in the cache folder after you visit it?
Test the output, not the settings. The settings page tells you the plugin thinks it’s configured. The output tells you the plugin is actually running.
Step four: rule out a plugin conflict
If a plugin shows as active, the debug log is clean, but the feature still isn’t working, a conflict with another plugin is the next most likely cause. Conflicts don’t always produce visible errors. One plugin can hook into the same function as another and silently override it, leaving the first plugin’s code unreachable without any error message to follow.
The standard test is to deactivate all other plugins except the one you’re testing and check whether the feature works. If it does, reactivate the others one at a time until the problem returns. The last plugin you activated before the problem came back is the conflict. Here’s a fuller walkthrough of finding WordPress plugin conflicts, including what to do when you can’t easily deactivate plugins on a live site.
This process is slower than it should be because WordPress gives you no visibility into which hooks a plugin is actually attached to. You’re essentially testing by elimination rather than by inspection.
Step five: check the active plugin list your server actually sees
Here’s a detail that trips people up more than it should. The plugin list in your WordPress dashboard is what your WordPress installation has registered. But if you’re running a caching plugin, a CDN, or a server-level cache, there’s a chance the page you’re looking at is a cached copy from before you made the change. The server is serving a page that reflects the plugin state from an hour ago, and you’re troubleshooting against that stale picture.
Clear all caches — plugin caches, server caches, browser caches — before running any of these tests. Checking the plugin state through your debug log is more reliable than checking it through the dashboard, because the log is written at execution time, not served from a cache.
What visibility into the plugin layer actually looks like
The tests above are all things you can do manually. They work. They’re also slow, because you’re reconstructing a picture of what’s happening by testing one variable at a time, with no way to see the full plugin execution sequence at once.
When Loupely runs a capture, part of what it surfaces is the active plugin list your server reports at the moment of capture, alongside the hook execution trace for the request you’re diagnosing. That means instead of checking whether a plugin is active in the dashboard (which can be stale or misleading), you’re seeing what was actually loaded when the failure occurred. If a plugin that should be running isn’t in that list, or if it’s in the list but its hooks aren’t firing, the capture tells you that directly. You’re not testing by elimination. You’re reading the evidence.
If you’re spending regular time on this kind of diagnosis, that difference matters a lot.
The short version
Check the dashboard plugin list first: is it actually showing active? If yes, turn on your debug log and look for PHP errors referencing the plugin. If the log is clean, test the plugin’s actual output rather than its settings. If the output is wrong, test for conflicts by deactivating other plugins in sequence. Clear all caches before and during this process, or you risk testing against a picture of your site that’s already out of date.
Most plugin problems announce themselves clearly once you know where to look. The hours get wasted before you look in the right place. Start the diagnostic sequence at the layer you can verify, which is whether the plugin is actually running, before you spend time on the layer you can only assume, which is whether its configuration is correct.
