[wp-trac] [WordPress Trac] #29820: Smooth installation and updating of plugins and themes

[WordPress Trac]

#29820: Smooth installation and updating of plugins and themes
-----------------------------+---------------------------------------------
 Reporter:  markjaquith      |       Owner:
     Type:  task (blessed)   |      Status:  new
 Priority:  high             |   Milestone:  4.2
Component:  Upgrade/Install  |     Version:
 Severity:  normal           |  Resolution:
 Keywords:  ux-feedback      |     Focuses:  ui, javascript, administration
-----------------------------+---------------------------------------------

Comment (by ericlewis):

 * In attachment:29820.7.diff:

 * Make this work for multisite plugins screen.
 * On install screen, don't let users click the `.install-now` button if
 it's disabled (e.g. after the plugin is installed).
 * Move ajax handlers into `wp-admin/includes/ajax-actions.php`, and use
 `admin-ajax.php` to hook the action callbacks.
 * Use $upgrader->upgrade() instead of bulk_upgrade() when only updating
 one plugin.
 * Remove the dataType from the AJAX calls, as we have to expect the worst
 case response, and deal with it elegantly.
 * On a related note, remove the success and error callbacks from the AJAX
 calls in lieu of a complete callback. `jQuery.ajax()` tries to be smart
 and reads HTTP response codes to decide whether a response is successful.
 This doesn't play nicely with our JSON API, whch serves a 200 when we hit
 `wp_send_json_error()`.
 * Match our existing patterns for script localization. Use
 `window._wpUpdateSettings` instead of window.updates. Separate string
 localizations into its own property on this object. Remove "Text" suffix
 from variable names.
 * Add rudimentary error handlers no matter what comes back from the
 request. If we're delivered intelligent errors (WP_Error sent through
 `wp_json_send_error()`), display that in an `alert()` pop-up. If not, give
 a generic "Installation failed" or "Update failed." If on the plugin
 install screen, re-enable the install button. On the plugin list table,
 this will be a little more tricky. I'd like to put the HTML that was
 originally inside the div back, but this will require a persistent view
 tied to the AJAX request. Backbone, anyone?
 * @lgladdy's css modifications in attachment:29820.5.diff do help the
 plugin card button icon placement, but are awkward in the list table, so
 I've modified that CSS appropriately.

 Follow-up notes:

 * This implementation uses `$upgrader->bulk_upgrade( array( $plugin ) )`
 on the ajax handler rather than `$upgrader->upgrade( $plugin )`. This begs
 the question, what is the utility of two separate functions here?
 `bulk_upgrade()` has beefier internals, and will enable maintenance mode.
 cc @dd32.
 * Odd that we're installing and activating plugins immediately. This blurs
 the user's definition of "installing," and we'll have to intelligently
 handle how BuddyPress and other plugins redirect you to their About page
 on their activation hook, i.e. what
 [https://core.trac.wordpress.org/ticket/29820#comment:32 lgladdy brought
 up earlier].
 * Think we should move the queue checker to the response callback handlers
 rather than on an interval.
 * The list table row item doesn't lose the red background after updating,
 should do something there.

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