[wp-trac] [WordPress Trac] #31819: Shiny updates: more sophisticated locking

[WordPress Trac]

#31819: Shiny updates: more sophisticated locking
-------------------------------------+-------------------------------------
 Reporter:  DavidAnderson            |       Owner:  jorbin
     Type:  enhancement              |      Status:  assigned
 Priority:  normal                   |   Milestone:  4.2
Component:  Upgrade/Install          |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  shiny-updates has-patch  |     Focuses:  ui, javascript,
  dev-feedback                       |  administration
-------------------------------------+-------------------------------------

Comment (by DavidAnderson):

 @ericlewis: that approach was used by our "automatic backups" from
 May(-ish) 2013 onwards, until fairly recently. It has some significant
 problems, which caused unhappy users and support requests and we were glad
 to get rid of it. The biggest problem is that many shared web hosting
 setups are not generous in how much time they allow PHP to run before
 killing it off (and do not respect set_time_limit()) - or, if they are,
 the user may still have a gigantic amount of data in one of their tables.
 (When you've got 400,000 users of your plugin, the uncommon becomes a
 regular event). If the user's database and/or the plugin is large, and if
 they're also sending the backup to cloud storage, then there's a too-large
 risk that the backup will be killed before it can finish; and thus also
 before the update can go ahead. There's no way to know when the
 webserver's about to kill you off. (And sometimes, even if the backup had
 time to complete, the limit would be reached during the update process
 instead; the current updates screen in WordPress itself notes that the
 operation can take considerable time).

 Because of that issue, we switched methods, to have the backup started
 over AJAX and monitored from the browser. This allows the backup to be
 resumed from where it got up to, every time it gets killed off - and thus
 to run until it finishes. (UpdraftPlus backups are resumable/crash-safe -
 they can be killed off at any point and picked up again - even with
 400,000 users I don't believe we've had even one support request in the
 last 12 months due to PHP killing off a backup process at an inconvenient
 time that could not be resumed). Then, and only then, the updates can go
 ahead. Since switching approaches, we've seen support requests for
 automatic backups dry up: they just work.

 The other issue is getting feedback on the backup process. If it's done
 entirely during the back-end update progress whilst the page loads, then
 there's no reliable way to do this. Different PHP and webserver setups
 deal with output buffering differently, and often can't be over-ridden.
 It's normally possible to control it a little, but not always: the result
 is that many users see zero output reporting on progress until the backup
 finishes (or dies); or, they get every line of the log spewed over the
 screen.

 All being well, I'll look at the patch and send more thoughts early next
 week...

 Final bit: "Plugins should (try) not to depend on markup looking specific
 for critical path functionality, as it is subject to change." Of course.
 We certainly tried. But, it's a choice between tracking the WP "Updates"
 pages closely between versions, or using a method which requires a backup
 to complete inside the unknown maximum time that the webserver is going to
 allow PHP to run. The former option is ultimately much better for reliable
 backups.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/31819#comment:14>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform