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
Issue 5105: Process batches generated during drush config:import. #5106
base: 11.x
Are you sure you want to change the base?
Conversation
A module may choose to initiate a batch process from hook_install(). The batch process is executed when a module is enabled in UI, via /admin/modules, or via config sync via /admin/config/development/configuration. Additionally, `drush pm:enable mymodule` also executes the batch process. Update the `drush config:import` command to use the same technique as `drush pm:enable` to get and process batches after every sync step.
Its a little weird that config:import has to care about code in hook_install. What is the backtrace in the core /admin/config/development/configuration request when the batch gets processed? |
I'm not sure what the backtrace is. I'm not sure how to generate that for you. But I'm assuming this has to do with how drush handles batch operations. You manually execute this same code during
I would ask the same question about pm:enable - why would it need to care about the contents of a module's hook_install()? |
Because hook_install is about happens when enabling modules. config:import can result in enabling a module but thats more of a byproduct. Your patch may be right. My question is more about where to add the new code, and less about whether to add it. FYI A backtrace can be viewed with by putting a call to print_r(debug_backtrace()) in the code where you want to get the info. It sometimes works to add a die() after that in order to actually see the printed info. Otherwise a debugger can stop and show you same info. |
Oh, of course, I see - that makes sense. Thanks for explaining! :) I also wondered if this was the right place and/or whether it should be added to the core method that doImport says it's copying. I've tried to get a backtrace in a couple different spots, but I am getting out of memory errors on the line with I set a breakpoint at the end of the
However, they set the config sync as a batch with This is the stack from the config import batch's finish callback (
I don't think these stack traces are useful, but maybe they're useful to you? |
I suspect that the form API is just processing any batches that were created by submit handlers. See \Drupal\Core\Form\FormSubmitter::doSubmitForm. So technically Drush needs to add the 3 lines you added here for any command that mimics a form. So, I'm leaning towards merging this PR but am thinking a bit more. |
A module may choose to initiate a batch process from hook_install(). The batch process is executed when a module is enabled in UI, via /admin/modules, or via config sync via /admin/config/development/configuration. Additionally,
drush pm:enable mymodule
also executes the batch process. Update thedrush config:import
command to use the same technique asdrush pm:enable
to get and process batches after every sync step.