How to Check If a Plugin Is Active in WordPress With Code

You can check if a plugin is active in WordPress in under a minute, either on the Plugins screen or with one PHP function. The function is is_plugin_active(). It returns true or false for the plugin file you give it.

We ran every snippet below on a WordPress 7.1.3 test site with WooCommerce 11.2 in October 2026. Some older guides call is_plugin_active an action. It is a function, and a few other details in those guides are out of date.

This guide covers the Plugins screen, the PHP check, the class_exists() alternative and the Requires Plugins header. It also covers WP-CLI, multisite, how to confirm a check works and the mistakes that break it.

What Does the is_plugin_active Function Do?

The is_plugin_active() function takes one plugin file path and returns true if that plugin is on the active list. It returns false in every other case. WordPress core defines it in wp-admin/includes/plugin.php, and it works on single sites and on multisite.

Its official reference page names two limits. Only plugins in the plugins folder can be active, and plugins in the mu-plugins folder always return false. A must-use plugin has no active state to read.

It is a plain function that you call inside your own code and use in an if statement. It is not an action or a filter. Nothing hooks into it, and it never turns a plugin on or off.

Here is the smallest useful example:

if ( is_plugin_active( 'woocommerce/woocommerce.php' ) ) {
	// Runs only when WooCommerce is active.
}

Check If a Plugin Is Active in WordPress on the Plugins Screen

The quickest way to check if a plugin is active in WordPress needs no code at all. Open Plugins > Installed Plugins and look at the row for that plugin. An active plugin shows a Deactivate link, and an inactive one shows Activate.

Follow these steps on any site:

1. Log in to your dashboard and open Plugins > Installed Plugins.
2. Look at the links above the list. Each shows a count, such as Active (3) or Inactive (2).
3. Click Active to list only the running plugins. A plugin that is missing from that list is inactive or not installed.
   

This is the right check for a human. It cannot tell your code anything. The next sections cover the code route.

How to Find the Plugin File Path

Every code check needs the exact plugin file path before it can run. It is the folder name plus the main file name, such as woocommerce/woocommerce.php for WooCommerce. A wrong path raises no error and the function silently returns false instead.

The easiest place to read the exact path is the plugin file editor. Open Plugins > Plugin File Editor, pick the plugin and read the line that starts with File. WordPress shows a warning about direct edits first, which you can dismiss.

Only read the path and do not change the file.

You can also open the plugin folder over SFTP and read the main file name. The main file is the one with the Plugin Name header comment. Copy the path exactly as you see it, including every dash and letter case.

Check If a Plugin Is Active with is_plugin_active

To check a plugin in code, pass its file path to is_plugin_active() and branch on the result. Put the code in a small plugin of your own rather than in a theme file. That way it survives a theme change and does not break when the theme updates.

Here is a complete small plugin that shows an admin notice. It tells you whether WooCommerce is active:

<?php
/**
 * Plugin Name: Active Check Demo
 */
if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

add_action( 'admin_notices', function () {
	if ( is_plugin_active( 'woocommerce/woocommerce.php' ) ) {
		echo '<div class="notice notice-success"><p>WooCommerce is active. The extra feature can load.</p></div>';
	} else {
		echo '<div class="notice notice-warning"><p>This feature needs WooCommerce. Activate it first.</p></div>';
	}
} );

We activated this plugin on our test site with WooCommerce on. The green notice appeared on the Dashboard at once. With WooCommerce off, the amber notice appeared instead.

You can use the same pattern to skip code that needs another plugin. Wrap the dependent code in the if block and leave the rest of your plugin alone. If the other plugin is off, your code stays quiet and the site keeps working.

Does is_plugin_active Work on the Front End?

Yes, on current WordPress it works on the front end without any extra include file. WordPress now loads wp-admin/includes/plugin.php on every single request before it starts loading the active plugins of your site. Core made that change in changeset 59488 in December 2024 to stop plugin fatal errors.

On our WordPress 7.1.3 test site, a front end call to is_plugin_active() returned true with no include at all. Older guides tell you to add include_once first. That line is only needed on older WordPress versions.

If you must support an older version, add the include before your check. It is harmless on new versions:

include_once ABSPATH . 'wp-admin/includes/plugin.php';

Warning: Must-use plugins load before that file does. A top-level call to is_plugin_active() in a mu-plugin was undefined on our test site. Wrap the check in a plugins_loaded callback and it works, as the next snippet shows.

add_action( 'plugins_loaded', function () {
	if ( is_plugin_active( 'woocommerce/woocommerce.php' ) ) {
		// Safe to run plugin-dependent code.
	}
} );

Check for a Plugin with class_exists Instead

A class_exists() check asks whether the plugin’s code has loaded and ignores both the file path and the active list. You pass it a class name that the plugin defines, such as WooCommerce. It keeps working when the plugin folder name changes.

Run this check on plugins_loaded or later, because plugin classes only exist once the plugin has loaded. We tested it on the same site, and the check returned true for WooCommerce on the front end:

add_action( 'plugins_loaded', function () {
	if ( class_exists( 'WooCommerce' ) ) {
		// WooCommerce code is available.
	}
} );

The weak spot is the class name. If the plugin author renames the class in an update, your check silently fails. WordPress’s own dependency guide still advises keeping function_exists() and class_exists() checks next to the new header, because it handles no versions and no load order.

Declare a Plugin Dependency with the Requires Plugins Header

WordPress 6.5 added a Requires Plugins header that plugin authors can put in their main file. You list the slugs your plugin needs and WordPress blocks activation until those plugins are active. This moves the first check from your code to the Plugins screen.

Add one line to your plugin’s header comment. The value is a comma separated list of WordPress.org slugs, as the WordPress 6.5 dependency note explains:

/**
 * Plugin Name: Needs WooCommerce Demo
 * Requires Plugins: woocommerce
 */

We added that header to a demo plugin and turned WooCommerce off. WordPress showed a Requires line on the demo plugin and refused to activate it, as you can see below.

The header only covers the admin screens. When we ran wp plugin deactivate woocommerce over WP-CLI while the demo plugin was active, WordPress let it through. So keep one runtime check in your code as a safety net.

Check Plugin Status with WP-CLI

WP-CLI can check a plugin from the terminal with the wp plugin is-active command. It prints nothing on screen and sets an exit code that a deploy job can read instead. The WP-CLI command page says the exit code is 0 when active and 1 when not.

Run the command with the plugin slug and read the exit code afterward:

wp plugin is-active woocommerce
echo $?

On our test site this printed 0 for WooCommerce while it was active. It printed 1 for the inactive demo plugin and for a slug that does not exist. The --network flag checks network activation only.

This is the best check for deploy scripts. A script can run wp plugin is-active woocommerce || wp plugin activate woocommerce and stay quiet when the plugin is already on.

Multisite and the is_plugin_active_for_network Function

On a multisite network, is_plugin_active() also returns true for any plugin that is active across the whole network of sites. The separate is_plugin_active_for_network() function tells you only about activation for that entire network. It always returns false on a single site install.

Some guides say the plain function misses network-activated plugins. That is not true. The WordPress 7.1.3 source for is_plugin_active() checks the site list first and then calls is_plugin_active_for_network(), as the function reference for the network check describes.

We confirmed it on a test network. With WooCommerce network activated, both functions returned true. With WooCommerce active on one site only, is_plugin_active() returned true and is_plugin_active_for_network() returned false.

Use the network function when your code must behave differently for a network-wide plugin. For everyday dependency checks the plain function is enough.

How to Confirm Your Check Works

A check that fails quietly is worse than an error. Log the result of your check to a file and read that file back. Turn on WP_DEBUG_LOG in wp-config.php and WordPress saves messages from error_log() to wp-content/debug.log, as the WordPress debugging guide describes.

Add these constants above the line that says to stop editing:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Then log the result of your check:

error_log( 'WooCommerce check: ' . ( is_plugin_active( 'woocommerce/woocommerce.php' ) ? 'active' : 'not active' ) );

Load a page and open wp-content/debug.log. Our test site wrote “WooCommerce check: active” for the right path and “not active” for a deliberately wrong path.

The log lives on the server. The browser console never shows it, although some tutorials wrongly point you there.

Turn the constants off again when you finish testing. A debug log can grow large and may hold details you do not want public.

Which Check Should You Use?

Pick the check by what you need to know. Use the Plugins screen when you are the only person who needs the answer. Use is_plugin_active() for code that depends on a plugin file, and class_exists() for code that depends on a feature.

Use the Requires Plugins header to stop a dependent plugin from activating at all. Use WP-CLI for scripts and deploys. The table sums it up:

A solid setup uses two checks. The header blocks activation in the admin, and a plugins_loaded check covers every other path. That pair handles the cases the header cannot see.

Common Mistakes When You Check a Plugin

Most failed plugin checks come from five small errors that we ran into while testing. All five fail quietly and never raise a visible error or warning in your log. That is why they can eat an afternoon before you spot the cause.

Here they are in the order we hit them:

• Wrong path: A typo in the file name returns false without any warning. Copy the path from the file editor.
• Renamed folder: A plugin copied into a folder with a different name has a different path. Use class_exists() for those.
• Must-use plugins: The function returns false for anything in mu-plugins, even though the code is running.
• Early calls: Code in a mu-plugin that runs before plugins_loaded cannot see the function at all.
• Checking too early with classes: A class_exists() call before plugins_loaded returns false even for an active plugin.

Dependency checks look small. A plugin that breaks another plugin still costs real support time. If you need a custom plugin built with checks like these, our WordPress development services cover it.

If a plugin does cause a crash, two guides help. Read about checking for plugin conflicts and about fixing the fatal error when a plugin cannot be activated.

Conclusion

To check if a plugin is active in WordPress, look at the Plugins screen for a quick answer or call is_plugin_active() in code. Get the path right, run the check at the right time, and confirm the result in debug.log.

On current WordPress you no longer need the extra include on the front end. Add the Requires Plugins header for a hard block and keep a class_exists() check as a backup. For a larger build, see how to create a WooCommerce plugin the right way.

Frequently Asked Questions (FAQs)