Unable to disable any hooks

What version of Drush are you using?

Quick disclaimer, I'm not the original author so any other advice would be greatly appreciated. I think this is generally a side effect of drush updates.

We want to keep that alter check cause I think that keeps recursion from happening.

So the hook implements alter alters how the implementations are called.
Drush is supposed to boot the migrate boost.

I tried to make it more backwards compatible with this, but something is missing.

public static function bootDrush($command) {
    // Check if $command is an instance of ArgvInput.
    if ($command instanceof ArgvInput) {
      $command_name = $command->getFirstArgument();
    }
    else {
      // Assuming it's an array for backward compatibility.
      $command_name = $command['command'];
    }

    if (in_array($command_name, static::getConfig('commands'))) {
      static::enable();
    }
    else {
      static::disable();
    }
  }

So for some reason the enable command is not being called which means either the command name is not picked up or the commands config is failing.

Can you share your Drush version?

Thanks for getting back to me and sorry for omitting that rather important bit of info! I am using drush 12.5.3.0.

I'm not familiar with the inner workings of drush so I haven't been able to dig too deep yet, but initial debugging seems to indicate that functions such as initCommand(), boosterEnable() and bootDrush() only get called when running either of the Migrate Boost module's own commands (i.e. enable or reset). The rest of the time, the first thing that gets called seems to be MigrateBoost::alter().

I'll keep digging and feedback anything I find and if you have any ideas of where to look, I am all ears!

I have made what I think is some good progress on this - at least, it works, and it doesn't seem to interfere with drush commands other than the two this module is targetting. I have implemented 2 annotated hooks in MigrateBoostCommands which run before migrate:import and migrate:rollback (one callback to target each command) and simply call MigrateBoost::enable().

I have created a fork and updated the file on GitHub, but this is my first foray into non-patch contribution, so if I need to do anything else to make it visible or otherwise complete the process, please let me know!

Oh that looks good, I'll try to test it in a bit!

dwb17 → changed the visibility of the branch 3472566-unable-to-disable to hidden.

dwb17 → changed the visibility of the branch 3472566-unable-to-disable to active.

I've merged this in, I left it in .dev so it can be tested a bit.

Automatically closed - issue fixed for 2 weeks with no activity.

Running the official 1.0.1 version.

I hit the same problem as the original poster, where hooks aren't disabled, and only become disabled when commenting the if clause in alter(). It appears though the disabling only happens for the first item in a migration — alas, hooks run for all the other items.

Hence I would gladly test the 1.0.x-dev version that seems to fix the issue.

But real life means I'm stuck with drush version 12. Customer hosting currently will not upgrade post PHP-8.2 — drush version 13 requires PHP-8.3.

I'm quite glazed-eye when looking at the code, could you please tell me what part of the patch requires drush version 13, so that I can find a workaround, and perhaps submit a patch to make migrate_boost compatible for crusty old environments such as the one I have to deal with?

Thank you,

Hi ptaff,

I am also on drush 12, so having installed the dev version of Migrate Boost manually to get round Composer's refusal to add it, I think I have found what needs changing to the dev version of this module to allow it to work with both Drush 12 and 13:

Move the file to

I have tested this with both Drush 12 and Drush 13 so I am pretty confident that it is a universal solution. The only other required change would be setting the composer.json dependency to drush 12.

If you're still on drush 12 you must be on drupal 10 right? The initial alpha 1 version should still work for you.

Yup, D10.4.4 to be precise. Until ptaff posted here I was just using my tweaked version from the MR via a composer-applied patch file on the current release. The possibility of going back to an official version intrigued me, hence my renewed dabbling :)

Given that my suggestion doesn't compromise the Drush 13 functionality (that I can see - I am very happy to be corrected), is there any reason not to have a more widely compatible codebase?

Can you put that on an MR so I can test it? Drush changed how commands are registered between 12 and 13 as far as I know.

Certainly. I had already considered it but I'm not sure how to since this issue already has an MR. Can you enlighten me?

As for the correct folders for Drush, that confused me as well. Whilst it is true that Drush 12 requires commandfiles to be in src/Drush/Commands, we are actually using pre-command hooks here which I guess may work differently. Whilst I can't find a single example or indication of where the pre-commands should be placed, I can only confirm empirically that Drush 13 definitely doesn't find them in src/Commands.

This is the only reference I have found: https://www.drush.org/13.x/commands/

nicxvan → changed the visibility of the branch 3472566-unable-to-disable to hidden.

nicxvan → changed the visibility of the branch 1.0.x to hidden.

I created a new branch for you to use, please use the issue instructions to pull down the drush12 branch and push there.
You can create an MR from that once you're ready and set it to needs review.

Any chance you can solve those failures?

Any chance you can solve those failures?

It would appear the answer is "yes"! That was my first real foray into GitLab...