[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