Not interrupting the network update, even if errors are detected

[luuzan@…]

My installation
3.2.1 multi-site installation with almost 8000 sites.

The issue
During the network update, I kept getting this error message :
Warning! Problem updating ​http://username.example.com. Your server may not be able to connect to sites running on it. Error message: 0: Empty reply from server.
The problem is that the network update script (/wp-admin/network/upgrade.php) dies every time an error is detected, so I had to reload the page every time. With nearly 8000 sites to update, it was impossible, so I modified that script.

Suggested enhancement
Enhance the network update script so that it doesn't die at each error, logs the error and continues. A second run on the unsuccessful upgrades would also be nice.

[ocean90]

Related: #11869

[luuzan@…]

And what would be even sweater is the possibility to choose

• the batch size : upgrade 5 blogs at once or 10, 20, etc
• the timeout of the requests : 120 seconds or 300 seconds, etc

In my case, what seemed to have solved to problem is increasing the timeout to 300 seconds.

[SergeyBiryukov]

18292.patch​ would allow to continue updating the remaining sites.

Doesn't touch UI, leaving that for #11869.

[nacin]

The problem is that doing this will still cause the JS to fire, which means you'll only see the error message if you're paying attention. We really should just implement #11869.

[jeremyfelt]

I was about to close this and defer to #11869 for our long term goals, but then realized I've been using a modified version in production for a bit. :)

18292.diff outputs the warning and stops the auto-next behavior if a warning is output.

This will result in an output of 5 sites each time, with those that have errors listed among those that were successful.

It may be worth it to put this in now while the right time for #11869 awaits.

Feedback and testing, please!

[jeremyfelt]

This is a case where we can do a lot better by re-evaluation the process used during a network upgrade. Closing this in favor of #11869, which should also take this scenario into account.