I'm trying to build a child plugin which needs another parent plugin to work correctly. I've managed it so far, that the child plugin can't be activated when the parent plugin isn't installed or activated.

Now I'm working on the point that the child plugin is deactivated on the moment when the parent plugin is deactivated. I'm trying to hook in on the

add_action('deactivated_plugin', 'functionxxx')

But it look's like, when doing some dump and die in the core WordPress files, that at first it deactivated my child plugin and then tries to deactivate the parent plugin. But when it deactivates the parent plugin, I can see my child-plugin in the list with activated plugins.

My code so far:

Plugin base file:


    Plugin Name: xxx
    Plugin URI: 
    Author URI: 

require_once __DIR__ . '/vendor/autoload.php';

new Test();

Test Class


    class Test
        public function __construct()
            add_action('deactivated_plugin', [$this, 'detectPluginDeactivation'])

        public function detectPluginDeactivation($plugin): void
            if ($plugin === 'xxx') {
  • 2
    Most plugins i know don't deactivate themselves, but instead they check very early on if their dependencies are met, and if they aren't, they show a banner in the admin and don't load any of their files. Otherwise what you're trying to do is bad UX as the plugin mysteriously deactivates itself without explanation – Tom J Nowell Apr 12 at 10:59
  • The plugin is checking right now on activation if the parent plugin is installed and active, as said in the original question, so that is not the problem. Because the plugin is used only internal, the UX problem isn't an issue for us. – Martijn Bastiaansen Apr 12 at 11:22
  • maybe you could just use register_deactivation_hook for this? set the argument to the parent plugin filename and the callback function to deactivate the child plugin? – majick Apr 12 at 15:44
  • Still the same problem @majick . Call is working, but the child is reactivated – Martijn Bastiaansen Apr 15 at 7:10
  • weird I dunno, maybe workaround by setting an option value on parent plugin deactivation hook, which could be checked for on next pageload init hook, recheck the parent plugin state and force-deactivate the child plugin. that's what i'd do anyway. ;-) – majick Apr 16 at 14:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.