[wp-trac] [WordPress Trac] #9757: Allow Plugin/Theme updates from a uploaded .zip file.

[WordPress Trac]

#9757: Allow Plugin/Theme updates from a uploaded .zip file.
-------------------------------------------------+-------------------------
 Reporter:  hakre                                |       Owner:  (none)
     Type:  feature request                      |      Status:  assigned
 Priority:  high                                 |   Milestone:  5.5
Component:  Upgrade/Install                      |     Version:  2.8
 Severity:  normal                               |  Resolution:
 Keywords:  dev-feedback has-patch early needs-  |     Focuses:  ui, ui-
  dev-note commit                                |  copy
-------------------------------------------------+-------------------------

Comment (by desrosj):

 This latest revision looks awesome! Really excited about this.

 I [https://github.com/WordPress/wordpress-develop/pull/395 created and
 linked a new PR] to make reviewing the code easier and to confirm the
 tests are passing on Travis.

 Because the [https://github.com/WordPress/wordpress-develop/pull/395/files
 #diff-d214ef92b2d8adbe0af81fc77e4078a5R169 `install()` method is used], I
 don't think that the current implementation would place the site in
 maintenance mode while the upgrade is applied. If a plugin or theme is
 active, this could cause some problems.

 Placing this before and after the `$upgrader->install()` call (toggling
 the boolean) should solve that problem and prevent a user from stumbling
 on a broken site at during an update.
 {{{
 if ( is_plugin_active() ) {
     $upgrader->maintenance_mode( true );
 }
 }}}


 Few more small thoughts, but I don't think any of these are a blocker for
 committing to include in beta:
 - When the PHP or WordPress requirements are not met, can we link to the
 HelpHub so that the user has some direction: Maybe this page:
 https://wordpress.org/support/update-php/?
 - Would it make more sense to create an array of data and
 [https://github.com/WordPress/wordpress-develop/pull/395/files#diff-
 84f206c9515d9ad843b821ac8d8d526cR278 pass that to this filter] before
 creating the HTML output? If not, I think it makes sense to also
 [https://github.com/WordPress/wordpress-develop/pull/395/files#diff-
 84f206c9515d9ad843b821ac8d8d526cR228 pass the `$rows` variable] to the
 hook (and maybe this should also be filterable?).

 Updated in the latest patch [attachment:"9757.2.diff"]:
 - This action hook is a bit weirdly worded: `upgrader_overwrited_package`.
 The patch replaces that with `upgrader_overwrote_package` (also toyed with
 `upgrader_overwritten_package`). Also, I clarified the docs to state the
 hook is only fired when the upgrader ''successfully'' overwrites the old
 package.

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