WordPress.org

Make WordPress Core

Opened 10 years ago

Last modified 3 years ago

#11869 new enhancement

Multisite upgrade notice at wpmu-upgrade-site.php isn't steadily visible.

Reported by: jane Owned by:
Milestone: Future Release Priority: normal
Severity: minor Version: 3.0
Component: Upgrade/Install Keywords: needs-patch
Focuses: multisite Cc:
PR Number:

Description

When upgrading (Site Admin > Upgrade) wordcamp.org, it started upgrading each site and flashing a list of 5 sites at a time that had been upgraded (too quickly to really be read beyond the first item in each list). When it flashed through all the screens, it showed "All done!" and nothing else.

Preferred UX would be to list the sites in order as they are upgraded but in a single persistent list rather than in flashing batches of five, and to show the all-done message on the same screen, with the list of everything that has been upgraded. It would be good to have the text appear at bottom of list (in sequence) but to also drop in an alert message at top of screen.

Attachments (3)

11869.diff (4.8 KB) - added by ocean90 10 years ago.
Its not perfect, only a first try.
ajax_upgrade_script_incomplete.diff (5.9 KB) - added by ptahdunbar 10 years ago.
ajax_upgrade_works.diff (8.6 KB) - added by ocean90 10 years ago.

Download all attachments as: .zip

Change History (24)

#1 @wpmuguru
10 years ago

If we were to do all the site upgrades in sequence it would probably dramatically increase the failure rate of upgrades on larger sites. The 5 sites per screen with the short delay between screens is most likely a compromise between the speed of the upgrade and success rate of upgrades. Active plugins also affect the duration of the upgrade.

I don't have access to statistics for the server capacity distribution across existing installs, so I wouldn't be comfortable with changing the number per screen without a second opinion.

Some things that we could do are:

  • add a running tally at the top of the screen showing a total of how many updated
  • include the blog id & description with each site listed and a success/failure note
  • increase the delay between pages so the page is visible longer
  • on a failure give an option to retry that site and an option to proceed with the next one after the failed site (2nd opinion on this as well)

#2 @donncha
10 years ago

The upgrades could be done by using admin-ajax.php and AJAX techniques to do what Jane suggests. I presume that Javascript would keep running beyond the usual 30 second or 60 second timeout because it's an actual script running in the browser.

It would probably have to fetch a list of blogs at a time, say 10 to 20, to upgrade then call admin-ajax.php to do the upgrade on that blog_id. It could also send a page number in the same way the current page does to page through the list of blogs.

We definitely need to handle failures better.

#3 @wpmuguru
10 years ago

  • Keywords needs-patch added

#4 @ocean90
10 years ago

I created a first version, how it looks: http://grab.by/3Ew4

For the code you can take a look at the attachment.

@ocean90
10 years ago

Its not perfect, only a first try.

#5 @ptahdunbar
10 years ago

Logic behind ajax_upgrade_script_incomplete.diff

The goal is to upgrade all sites on the network.

The script grabs the first 5, gives the user some feedback so they know which blogs are being updated, and once their done, update their status (either success, or failed.) grab the next batch and rise and repeat until there's no more sites left.

Hopefully that'll give you some sort of starting point. Sorry I wasn't able to finish it :/

#6 @ocean90
10 years ago

In ajax_upgrade_works.diff I completed the idea of ptahdunbar, so that the update process works.
If there is a failure in a site, we have now a retry button. If you click the button this site will be updated again.

Maybe wpmuguru and donncha can give some feedback on this idea.

#7 @nacin
10 years ago

  • Reporter changed from janeforshort to jane

We need a solution that works without JS. Having the original idea in place -- a Next button that runs the next five -- would suffice.

#8 @westi
10 years ago

  • Milestone changed from 3.0 to 3.1
  • Version set to 3.0

This feels like something we could improve on in the future so moving to 3.1 for now.

#9 @nacin
10 years ago

(In [14678]) Use upgrade_db instead of step=1 in ms-upgrade-network. Also, no need to check spam/deleted/archived as that is in the query. see #11869.

#10 @nacin
10 years ago

I had been saving two incremental improvements for some time, now that this is being moved out of 3.1 I figured I would commit.

#11 @nacin
9 years ago

  • Milestone changed from Awaiting Triage to Future Release

#12 @ocean90
9 years ago

  • Keywords updates removed

Related: #16723

#14 @nacin
8 years ago

Could we not hit upgrade.php with a simple ajax call, rather than an ajax call that leads to an HTTP call?

#15 @jeremyfelt
6 years ago

  • Component changed from Multisite to Upgrade/Install
  • Focuses multisite added

#16 @jeremyfelt
5 years ago

This should be the ticket we use to improve the global upgrade process with ajax calls rather than refreshing the page over and over again.

Related: #24922, #18292. See also #22589 for introducing a wp-admin/network/admin-ajax.php.

This ticket was mentioned in Slack in #core-multisite by jeremyfelt. View the logs.


4 years ago

This ticket was mentioned in Slack in #core-multisite by jeremyfelt. View the logs.


4 years ago

This ticket was mentioned in Slack in #core-multisite by jeremyfelt. View the logs.


3 years ago

This ticket was mentioned in Slack in #core-multisite by sergey. View the logs.


3 years ago

Note: See TracTickets for help on using tickets.