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

WordPress Trac noreply at wordpress.org
Wed Feb 4 15:57:48 UTC 2015


#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 adamsilverstein):

 Nice work Eric!

 This is awesome, great progress here. Inspired to test and take a stab at
 some of your follow up notes :)

 Cheers!


 Replying to [comment:39 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:41>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list