Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

hook_init has a different bootstrap level for global commands and module commands #3058

Closed
joachim-n opened this issue Oct 11, 2017 · 8 comments

Comments

@joachim-n
Copy link
Contributor

I've been running my command as a module command to get around #2918, and it's been working ok.

Now I'm testing the PR to fix that issue, #3052, and my command crashes.

The reason is that my call to drush_drupal_version() in my command's hook_init gets a FALSE, where before it got a version number.

Here's some test code:

  /**
   * Test hello.
   *
   * @command cb-hi
   * @bootstrap DRUSH_BOOTSTRAP_DRUPAL_FULL
   */
  public function commandHi() {
    dump(drush_drupal_version());
    dump('hello!');
  }

  /**
   * Initialize Drupal Code Builder before a command runs.
   *
   * @hook init cb-hi
   */
  public function initHi() {
    dump(drush_drupal_version());
    dump('init');
  }

The output running that as a global command is is:

false
"init"
"8.4.0-dev"
"hello!"

Whereas if running as a module command, the Drupal core version number would be output both times.

@greg-1-anderson
Copy link
Member

Add a @bootstrap full annotation to your command(s).

@joachim-n
Copy link
Contributor Author

Same result.

I already had

    * @bootstrap DRUSH_BOOTSTRAP_DRUPAL_FULL

-- isn't that the same thing?

@greg-1-anderson
Copy link
Member

greg-1-anderson commented Oct 11, 2017

Run with --debug and see if the bootstrap hook is being called. Does drush status show that Drush is connecting to your database?

@greg-1-anderson
Copy link
Member

@joachim-n Oh, wait, sorry, you are talking explicitly about @hook init. Bootstrapping happens as part of hook init (unless your command is part of a module - as modules commands are not discovered until bootstrap full).

If you'd like your init hook to have access to the bootstrapped site, use @hook post-init.

Maybe we could alter things so that the bootstrap hook happens at the end of pre-init (or the very beginning of the init hook, before all other hooks). That might produce more intuitive results. However, there currently isn't any way to order hooks within a phase. Add an "after-pre" phase? 😛 That's probably too much.

@joachim-n
Copy link
Contributor Author

joachim-n commented Oct 11, 2017

Maybe we could alter things so that the bootstrap hook happens at the end of pre-init (or the very beginning of the init hook, before all other hooks).

That might be an idea.

At the moment, specifying @bootstrap full for a command doesn't actually mean the same thing in the code for a global or a module command, which is a bit of an inconsistency in the API for commands.

PS. Confirming that using post-init works.

@weitzman
Copy link
Member

Closing. Please post here if this needs re-opening.

@joachim-n
Copy link
Contributor Author

I think it does -- there is an inconsistency in the API.

If I have a command in a module that uses @bootstrap full and has a hook_init, and try to copy that code to a command in a global location with the same bootstrap level, then that code will fail. That goes against developer expectations.

@greg-1-anderson
Copy link
Member

@joachim-n Sorry, that is by design and cannot be fixed. Note that in Drush 8 an earlier, the behavior of your command hooks vary based on the bootstrap level, and module commands were discovered during bootstrap full as well, so nothing has really changed.

We could clarify the documentation a bit, though. Docs PRs welcome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants