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

[WordPress Trac]

#31819: Shiny updates: more sophisticated locking
--------------------------------------------+-----------------------------
 Reporter:  DavidAnderson                   |      Owner:
     Type:  enhancement                     |     Status:  new
 Priority:  normal                          |  Milestone:  Awaiting Review
Component:  Upgrade/Install                 |    Version:  trunk
 Severity:  normal                          |   Keywords:
  Focuses:  ui, javascript, administration  |
--------------------------------------------+-----------------------------
 Now that the "shiny updates" code for 4.2 has settled down, I've been able
 to have a look.

 I develop a plugin (UpdraftPlus - the most installed WP backup plugin;
 400,000+ current installs) that hooks into plugin updates (in the paid
 version), and runs a backup before updating. (So, if the update is broken,
 you have a convenient backup from just before). Communication on the
 backup state goes between browser and back-end over AJAX. When the back-
 end completes, the update operation then proceeds.

 Of course, we want to retain this functionality with shiny updates.

 Looking at the shiny updates code, it looks like the best way to
 accomplish this is for my code to set wp.updates.updateLock to prevent the
 update going ahead, until it's ready ... and then set it back to false and
 call wp.updates.queueChecker().

 This looks like it'll work, though the filesystem credentials dialog makes
 it slightly more complicated (but I think we can work with that too).

 However, I am concerned that a binary boolean lock is inflexible, and
 makes the shiny updates process difficult and a bit hack-ish to plug into,
 possibly setting us up for future complications or unanticipated
 complications out in the wild.

 It'd be ideal if WP had JavaScript filters (see: #21170), but they're not
 there yet. So, I suggest that instead of a boolean lock, instead
 wp.updates.updateLock becomes an array of functions. When the lock status
 needs checking, the functions are each called.

 Alternatively, and more simply, instead of a boolean, an integer could be
 used, and different agents wanting to lock could set different bits (the
 core code would use some, and others would be left for plugins).

 Thoughts?

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