- 🇺🇸United States dww
Now that 📌 Deprecate/remove the ability to update a module from a URL and authorize.php Active and child issues are done, this code is all deprecated and will be removed in D12.
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.
Closed: won't fix
11.0 🔥
update.module
After being applied to the 8.x branch, it should be considered for backport to the 7.x branch. Note: This tag should generally remain even after the backport has been written, approved, and committed.
The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
Now that 📌 Deprecate/remove the ability to update a module from a URL and authorize.php Active and child issues are done, this code is all deprecated and will be removed in D12.