When developing a WordPress plugin or theme, you often need to check if another plugin is currently active. The standard way to do this is by using the is_plugin_active() function. However, many developers encounter a frustrating hurdle: the dreaded Fatal error: Call to undefined function is_plugin_active().

This error occurs because WordPress does not load all of its functions for every single request. To keep the platform fast, specific functions—especially those related to the admin dashboard—are only loaded when they are absolutely necessary. If you try to call is_plugin_active() on the frontend or too early in the WordPress boot sequence, the function simply hasn't been defined yet.

In this guide, we will explore why this happens and provide four distinct methods to solve it, depending on your specific use case.

Why is_plugin_active() is Often Undefined

The is_plugin_active() function is defined in the file wp-admin/includes/plugin.php. As the directory name suggests, this is an administrative file. By default, WordPress only loads this file when you are inside the /wp-admin/ area.

If your code runs on the frontend (the part of the site visitors see) or if your plugin's main file executes before the admin files are included, the function will not be available. This is a common issue when trying to run dependency checks in the root file of a plugin.

Method 1: Manually Including the Plugin API

The most straightforward way to fix the error is to manually include the file that contains the function definition. You can do this by checking if the function exists and, if not, requiring the necessary file using the ABSPATH constant.

// Ensure the function is available
if ( ! function_exists( 'is_plugin_active' ) ) {
    require_once( ABSPATH . 'wp-admin/includes/plugin.php' );
}

// Now you can safely use it
if ( is_plugin_active( 'woocommerce/woocommerce.php' ) ) {
    // Execute code that depends on WooCommerce
}

This approach is highly effective when you need to perform a check immediately within your plugin's main file or inside a frontend template.

Method 2: Using the Correct WordPress Hooks

If you are working strictly within the WordPress admin area, the error usually stems from calling the function too early. For example, calling it directly in the plugin's global scope is often too soon. Instead, you should wrap your logic in a hook that fires after the administrative environment is fully initialized.

Using the admin_init hook ensures that wp-admin/includes/plugin.php has already been loaded by the core.

function my_plugin_dependency_check() {
    if ( is_plugin_active( 'contact-form-7/wp-contact-form-7.php' ) ) {
        // Your logic here
    }
}
add_action( 'admin_init', 'my_plugin_dependency_check' );

Note that admin_init is generally preferred over admin_menu for this specific purpose, as it guarantees the environment is ready for plugin-related logic.

Method 3: The Frontend-Safe Approach (Direct Option Check)

If you want to check for an active plugin on the frontend without the overhead of loading an admin-only file, you can query the WordPress database directly. Active plugins are stored in the active_plugins option within the wp_options table.

This method is lightweight and won't cause "undefined function" errors regardless of where the code is executed.

/**
 * A lightweight way to check if a plugin is active without loading admin files
 */
function is_plugin_active_frontend( $plugin_path ) {
    $active_plugins = (array) get_option( 'active_plugins', array() );
    return in_array( $plugin_path, $active_plugins );
}

// Usage
if ( is_plugin_active_frontend( 'elementor/elementor.php' ) ) {
    // Elementor is active
}

For Multisite installations, you should also check the network-wide active plugins using get_site_option( 'active_sitewide_plugins' ) to ensure complete accuracy.

Method 4: Handling Page Builder Specifics (Elementor Example)

If you are developing extensions for page builders like Elementor, you might find that is_plugin_active works in the editor but fails on the live site. In these cases, you can combine the check with the builder's own state detection.

if ( did_action( 'elementor/loaded' ) ) {
    if ( \Elementor\Plugin::$instance->editor->is_edit_mode() && is_plugin_active( 'some-plugin/some-plugin.php' ) ) {
        // Logic specific to the editor view
    }
}

Frequently Asked Questions

Can I use is_plugin_active() in my theme's functions.php?

Yes, but you will likely need to use Method 1 (manually including plugin.php) because functions.php is loaded on both the frontend and backend. Without including the file, your site will crash on the frontend with a fatal error.

Is there a performance hit to including wp-admin/includes/plugin.php?

There is a minor performance cost because you are loading additional PHP code into memory. For high-traffic frontend pages, Method 3 (using get_option) is generally the more optimized choice as it avoids loading the entire Admin Plugin API.

Why shouldn't I just create my own function with the same name?

Never declare a function with the same name as a WordPress core function (like is_plugin_active) unless you wrap it in a if ( ! function_exists() ) check. If WordPress eventually loads the core file, your site will trigger a "Cannot redeclare function" error and go down.

Wrapping Up

The is_plugin_active function is a powerful tool for managing plugin dependencies, but its "admin-only" nature makes it a common source of errors for developers. By understanding the WordPress load order, you can choose the best strategy for your project:

  1. Use Method 1 for quick fixes in plugin headers or themes.
  2. Use Method 2 for standard admin-side logic.
  3. Use Method 3 for performance-critical frontend checks.

Always remember to use the full plugin path (e.g., folder-name/filename.php) rather than just the plugin name when performing these checks.