in Snippets, Tutorials, WordPress

Check if Another WordPress Plugin is Active

Recently I’ve been spending a lot of time working on my new plugin Recipe Hero. Essentially, the plugin is an open-source, free item, but the extensions that I (and others) make for it, can be either free or premium.

Similar to WooCommerce, Easy Digital Downloads, WP Job Manager and even WordPress itself, the core item itself is a simple, sufficient plugin, but the functionality to take it that little bit further and do something ‘out of the norm’, should be in its own separate ‘extension’ or ‘add-on’.

However, what if a user doesn’t realise that and tries to add an extension without the ‘core’ plugin? Or how about when a user deactivates the core plugin but forgets about deactivating the extensions. We need to put a check in for that or you’re going to be dealing with some angry users.

WooCommerce actually has a great article on Creating a plugin for WooCommerce, that gives it a great example of how to check for another plugin. A lot of people like to use is_plugin_active, but I like WooCommerce’s method better, as is_plugin_active is a little bit less flexible. Themergency also has a post looking at different methods to check if a plugin is active.

The approach WooCommerce takes is to check if the woocommerce/woocommerce.php file is in the array of active plugins, using PHP’s in_array function.

So if we wanted to check if WooCommerce was active, they suggest to use the following:

In a Recipe Hero extension, Recipe Hero Likes, I need to check if Recipe Hero is active before requiring a couple files that contain most of the extension’s functions. The following is what I use:

How do you like to check if a plugin is active? Do you think there’s an issue using in_array? Let me know in the comments!

Write a Comment


  1. This comes at a perfect time for some research I’ve been doing about how to test for another plugin to be active. I’ve found the ‘active_plugins’ array very unreliable for testing this, as in some (and increasingly popular) use cases the plugins will not be there. Having a filter on there covers this, but it’s not bullet proof by default.

    One of the use cases where I’ve been running into issues related to this recently, is loading a bunch of plugins via Composer (via WordPress Packagist) in a different directory than the default ‘WP_PLUGIN_DIR’, in addition to the default directory. I forked the WP-Plugin-Directories and started working on a plug and play solution for this to cover our need to load plugins via Composer in a different directory (‘wp-content/plugins/vendor-plugins’).

    Now this all works fine, just the plugins that use a similar way to detect another plugin being active (without a filter) cause some trouble. Looking forward to read how other people tackle this issue. 🙂

    • Yeah, this definitely isn’t foolproof. Another issue I see a lot in WC Support is people using a ThemeForest theme and how that / Envato Toolkit is installing WooCommerce in an envato-toolkit (or something like that) folder, which is very frustrating.

      Very interested to see what you’ve come up with! 🙂

      • Hey Bryce,

        I’m 99% sure it’s not Envato Toolkit that’s doing it, though I haven’t been through all the code. It must be the themes themeselves. Do you have an example of one that does this?

        I’d like to understand what they are doing. We might be able to include something about not changing the default folder name in a future version of our submission requirements (though obviously can’t promise that at this point).

        • Yeah, I’m not 100% sure of the cause but what we’ll tend to see is that on those sites, WooCommerce’s folder is called envato-wordpress-toolkit. As a lot of our extensions do a check for the woocommerce folder, it causes issues.

          I’ve seen it with lots of different themes but an example would be Flatsome.

  2. Problem with using the check like this is as soon as you install the plugin under a different folder, like woocommerce-test for example, the check will fail.

    In theory you should not rely on the folder name staying the same as with the latest theme craze of bundling everything, theme authors are bundling plugin and then installing them into different folders on your site.

    Same goes for including assets, never hardcode the plugin folder into the directory name or url.

  3. Yeah, I never use the ‘active_plugins’ array for the reasons mentioned in the other comments. Instead I use:

    function plugin_name_init() {
    if ( function_exists ( 'main_function_from_other_plugin' ) ) {

    add_action( 'plugins_loaded', 'plugin_name_init' );

    If the other plugin changes and renames the functions I'm checking, it might break my code, but it's less likely than people changing the folder. Typically, I'm using it in extensions for my own plugin, so I *should* be able to keep the function names in sync. No problems so far anyway.

    • Yeah, I like to do the same with Classes as they tend to change less. Again, reliant on the plugin not changing the name in the future.

  4. Another fun thing to add here: WooCommerce extensions ship with the WC_Dependencies class, that doesn’t have the filter as the documentation recommends. 🙂

    So to work around this, I had to add a custom version of that class in the Vendor Loader (the plugin I mentioned earlier) that gets loaded before anything WooCommerce is loaded and allows me to add my active_plugins_vendor option in.