On certain server setups, when installing or updating a module the Update Manager code will force the associated batch to be processed immediately from within a form submit handler. This means that any submit handlers that run afterwards will never run, since processing a batch calls drupal_goto().
The standard way to handle this situation is to let the form API initiate the batch process for you, since it automatically makes sure to process the batch only after all submit handlers have run. There's never really a good reason to call batch_process() yourself from within a form submit handler.
The attached patch makes the Update Manager use that method.
Comments
Comment #1
bfroehle commentedTagging for possible backport to D7.
Comment #2
mbrett5062 commentedDavid, do we still want this in for 8.x, if so I can re-roll and move it forward. Just assign to me if you would like me to proceed.
Comment #3
kscheirerI say go for it!
Comment #4
mbrett5062 commentedRe-rolling against latest 8.x, patch to follow.
Comment #5
mbrett5062 commentedHere is the patch for latest 8.x.
Comment #6
mbrett5062 commentedNo longer able to work on this. And is probably redundant by now. Unassigned myself so someone else can take a look.
Comment #7
artem.ua commented5: drupal-update_manager_batch_set-1130146-5.patch queued for re-testing.
Comment #20
quietone commentedThank you for reporting this problem.
There has been no activity here for 9 years.
Is this still a problem?
Since we need more information to move forward with this issue, I am setting the status to Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Thanks!
Comment #21
dwwSad to say, but yes, it's still a problem.
Drupal\update\Form\UpdateReady::submitForm()is still directly invokingupdate_authorize_run_update()in some cases, which in turn callssystem_authorized_batch_process()which eventually callsbatch_process()which is the undesirable behavior explained in the summary.Not sure if "needs work" or "active" is more accurate at this point, since so much of the code has been refactored since #5. Also, looking at that patch, it's changing many things we don't need to change, and not changing what's being requested. So yeah, this is basically back to the drawing board at this point...
Comment #22
Ankit.Gupta commentedReroll the patch #5 with Drupal 9.4.x
Comment #23
pooja saraah commentedFixed failed commands on #22
Attached patch against Drupal 9.4.x
Comment #27
dwwNow that #3491731: [META] Remove the ability to update modules and themes via authorize.php and child issues are done, this code is all deprecated and will be removed in D12.