While developing a plugin, especially an add-on or a premium plugin, you would have to handle some use cases. One such use case for example would be, when activating a premium plugin, you would have to deactivate your freemium plugin. Or if your plugin was dependent on other plugins, you could check if those plugins are active before activating your plugin. Custom conditional logic can be added to your plugin, on activation and deactivation hooks.
[space]
Checking if a Dependent Plugin is Active
Say your plugin’s activation is dependent on another plugin. Then, you would need to check if the other plugin is active, before activating your plugin. This conditional logic for activating your plugin, will have to be added using the register_activation_hook provided by WordPress.
register_activation_hook(__FILE__, 'mypluginname_activation_logic');
where ‘mypluginname_activation_logic’ should be written in your main plugin file. In this function, you have to check if the dependent plugin is active.
function mypluginname_activation_logic() { //if dependent plugin is not active if (!is_plugin_active('abc/abc.php') ) { deactivate_plugins(plugin_basename(__FILE__)); } }
WordPress provides you with a functions is_plugin_active to check if the plugin is active. This function basically returns a true or false result. But the drawback here, is that you would have to know the exact plugin folder name and file name.
[space]
A more preferred option, is to check if a class or function created by the plugin exists using, class_exists or function_exists function. For example, the WooCommerce plugin creates the class ‘WooCommerce’. To check if WooCommerce plugin is active you could use:
if (class_exists('Woocommerce')) { // your code here }
But it is obvious that the drawback here is that, if the class or function name changes during plugin updates, this check will not work.
[space]
Deactivating another Plugin from your Plugin
To deactivate another plugin, you can use the function, deactivate_plugins function provided by WordPress. The deactivate function has to be called on the appropriate hook, depending on when the plugin should be deactivated. For example, to deactivate plugin ABC, when plugin XYZ is activated, we will have to hook into the plugin XYZ activation function, and deactivate ABC.
register_activation_hook(__FILE__, 'XYZ_activation'); function XYZ_activation() { deactivate_plugins('ABC/ABC.php'); }
The path for the plugin to be deactivated, has to be specified in the deactivate_plugins function.
[space]
Deactivating your Plugin if Dependent Plugin is Deactivated
Such a use case would arise when building a custom add-on or extension on a base plugin. In such a scenario, you would want to deactivate your add-on when the base plugin is deactivated. To do this, you have to hook to the deactivated_plugin action, and check if the plugin deactivated is the base plugin.
function detect_plugin_deactivation( $plugin, $network_activation ) { if ($plugin=="abc/abc.php") { deactivate_plugins(plugin_basename(__FILE__)); } } add_action( 'deactivated_plugin', 'detect_plugin_deactivation', 10, 2 );
Update 2026: If your plugin is on WordPress.org and has a hard dependency on another .org plugin, the Requires Plugins header is now the cleanest way to declare that relationship. It removes the need to write any deactivation logic for this specific case — WordPress handles it natively.
A Note on Must Use Plugins
All the use cases specified above are mostly to deactivate a plugin. The reason for this being, it is better not to activate a plugin on behalf of the user.
There may be some must use plugins you would want to activate automatically; such plugins can be created and placed inside the must use directory. For more information, you can refer to Must Use WordPress plugins in the WordPress developer documentation.
Wrapping Up
Plugin dependency handling in WordPress has come a long way. The hook-based patterns covered in this article — register_activation_hook, deactivated_plugin, is_plugin_active, and class_exists — remain the standard approach for commercial and private plugins. They give you full control over exactly when and how your plugin deactivates based on the state of its dependencies.
For a broader perspective on what goes into building a production-ready plugin, our unfiltered look at WordPress plugin development covers the full process end to end. And if you want to understand how advanced plugins extend and interact with WordPress at a deeper level, our piece on advanced WordPress plugins for customization is worth reading alongside this one.
If you’re building a plugin that needs custom dependency logic — conditional activation flows, freemium-to-premium switching, or complex multi-plugin coordination — our custom WordPress plugin development team can help you build it properly. For more involved custom builds, take a look at our full WordPress development services.
FAQ
What is the best way to check if a plugin is active in WordPress?
The most reliable method is is_plugin_active(‘plugin-folder/plugin-file.php’). If you do not know the exact folder and filename, checking for a class or function created by the plugin using class_exists() or function_exists() is a practical alternative, though it breaks if those identifiers change in a future plugin update.
Can I automatically deactivate my plugin when a dependency is deactivated?
Yes. Hook into the deactivated_plugin action, check whether the plugin being deactivated is your dependency, and call deactivate_plugins() on your own plugin if it is. The code example in the third section of this article covers exactly this pattern.
Should I automatically activate a plugin on behalf of the user?
No. WordPress best practice is to never auto-activate a plugin on behalf of the user. Instead, deactivate your plugin and display a clear admin notice explaining which dependency needs to be activated. Must Use plugins are a special exception — they activate automatically but require placing the plugin file in the wp-content/mu-plugins directory.
What is the Requires Plugins header in WordPress 6.5?
Introduced in WordPress 6.5 (April 2024), the Requires Plugins header lets you declare plugin dependencies directly in your plugin header file using the WordPress.org slug of the required plugin. WordPress then prevents your plugin from activating if the dependency is missing and prevents the dependency from being deactivated while your plugin is active. This only works for plugins hosted on WordPress.org.
Does the Requires Plugins header work for private or commercial plugins?
No. The Requires Plugins dependency system only covers plugins whose dependencies are in the WordPress.org Plugin Directory. For commercial plugins, private plugins, or plugins hosted outside of WordPress.org, you need to implement dependency checking manually using the hook-based approach covered in this article.
What is the difference between deactivate_plugins() and register_deactivation_hook()?
deactivate_plugins() is a function you call programmatically to deactivate one or more plugins. register_deactivation_hook() is a function you use to register a callback that runs when your own plugin is deactivated by the user. They serve different purposes: one triggers deactivation, the other responds to it.
