-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Comments
Add a |
Same result. I already had
-- isn't that the same thing? |
Run with |
@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 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. |
That might be an idea. At the moment, specifying PS. Confirming that using post-init works. |
Closing. Please post here if this needs re-opening. |
I think it does -- there is an inconsistency in the API. If I have a command in a module that uses |
@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. |
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:
The output running that as a global command is is:
Whereas if running as a module command, the Drupal core version number would be output both times.
The text was updated successfully, but these errors were encountered: