Make WordPress Core

Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#29820 closed task (blessed) (fixed)

Smooth installation and updating of plugins and themes

Reported by: markjaquith's profile markjaquith Owned by:
Milestone: 4.2 Priority: normal
Severity: normal Version:
Component: Upgrade/Install Keywords: shiny-updates
Focuses: ui, javascript, administration Cc:

Description

The "UI" for plugin installs and updates and the "UI" for theme updates (and combined updates) is about as friendly as the Linux boot sequence.

This is a tracking ticket for improving that whole experience, as a blessed effort for the WordPress 4.1 release.

@Pento has gotten started already: https://github.com/pento/shiny-updates (functional, but with minimal UI changes). So as a next step, we need to think about the UX we want, and then what we need to do UI-wise and PHP-wise to make that happen.

Making the installation and updates happen inline is paramount. Right now it is a jarring and unfriendly experience.

Attachments (18)

29820.diff (6.0 KB) - added by pento 9 years ago.
29820.2.diff (8.9 KB) - added by pento 9 years ago.
plugin-install-error.jpg (78.5 KB) - added by melchoyce 9 years ago.
plugin-ftp-2.jpg (428.9 KB) - added by melchoyce 9 years ago.
29820.3.diff (12.4 KB) - added by pento 9 years ago.
29820.4.diff (16.6 KB) - added by pento 9 years ago.
29820.5.diff (18.0 KB) - added by lgladdy 9 years ago.
Patch 5 with post-activation configuration URL support
29820.6.diff (17.5 KB) - added by lgladdy 9 years ago.
29820.7.diff (22.3 KB) - added by ericlewis 9 years ago.
29820.8.diff (22.6 KB) - added by adamsilverstein 9 years ago.
29820.9.diff (22.7 KB) - added by DrewAPicture 9 years ago.
Code style + escaping
29820.fix-for-comment-52.patch (599 bytes) - added by lgladdy 9 years ago.
Fixes @afercia's bug report in comment:52
29820.patch (3.1 KB) - added by iseulde 9 years ago.
29820-current-theme-update-flow.mp4 (478.5 KB) - added by ericlewis 9 years ago.
29820-new-theme-update-button.png (461.6 KB) - added by ericlewis 9 years ago.
Screen Shot 2015-02-15 at 4.09.25 PM.png (151.1 KB) - added by ericlewis 9 years ago.
29820.10.diff (8.0 KB) - added by jorbin 9 years ago.
29820.11.diff (6.7 KB) - added by jorbin 9 years ago.

Download all attachments as: .zip

Change History (115)

This ticket was mentioned in IRC in #wordpress-dev by MarkJaquith. View the logs.


9 years ago

#2 @dovyp
9 years ago

I can implement any wireframe someone puts up. Seems like the only real update needs to occur on the add plugins pane with flipping. The rest just works as is.

#3 @danieliser
9 years ago

I would add that if you are planning to change the entire UX and UI anyways it may be time to think about background installation via AJAX, so that if you search for something and want to install multiple you can click install now and it will in the background and come back letting you know its installed, further letting you activate it without leaving the page. If it redirects upon activation it could simply return the link in a lightbox where the user should visit to get started.

#4 @pento
9 years ago

#29877 was marked as a duplicate.

@pento
9 years ago

#5 @pento
9 years ago

29820.diff is a first pass at just adding updates to the "update now" link plugin list. It's just a simple example, because I'd like to think about some more difficult problems before we get too worried about implementation.

For this chunk, can we show progress in a nice way? It's probably well outside of the scope of this feature to implement serious estimations on progress, but it may be nice to show progress through the 4 steps of updates (downloading, unpacking, installing, removing old version). Can this be shown reliably? Does it provide useful information?

How do we handle failure? Show a message? Are there errors we can handle in a nicer manner?

Something to sleep on. I'll tackle this some more tomorrow. :-)

#6 @dd32
9 years ago

It's worth keeping in mind, that some users are forced to enter FTP details during updates.

This is one of those things that progressive enhancement feels warranted, where if you're in that situation, you simply miss out on the functionality. However, server configuration is a case where users don't have much of a choice or don't understand, so I guess we could simply prompt for their FTP details client-side and send it with the XHR request..

This also skips the plugin deactivate/reactivate dance we currently do (in some situations at least) - If a plugin causes a fatal post-update or only partially completes, it could cause some white screens.

That being said, Nice work @pento :)

#7 @ScottSmith
9 years ago

It would be nice to see theme installation and updates get some of the features that plugins have like change logs so theme devs can let users know of any breaking changes or new features.

#8 @lgladdy
9 years ago

What about some way for a plugin to define what should happen once it's been installed, so that rather than needing to add their own message, plugin developers could just define a "configure URL", so that "Installed!" button could be "Installed - Configure now" or something that fits and sounds way better.

Last edited 9 years ago by lgladdy (previous) (diff)

This ticket was mentioned in IRC in #wordpress-ui by Dovy. View the logs.


9 years ago

This ticket was mentioned in IRC in #wordpress-dev by Dovy. View the logs.


9 years ago

@pento
9 years ago

#11 @pento
9 years ago

29820.2.diff

  • Switch to using Plugin_Upgrader::bulk_upgrade(), so that maintenance mode is used for currently active plugins.
  • Add a client side queue for updates, so that users can click as many updates as they like, without needing to wait for the previous one to finish.
  • Add support for the Bulk Action checkboxen.
  • Decrement/remove the "Updates Available" link, as plugins are updated.

An interesting problem is going to be handling multiple users (or one user with multiple tabs) clicking the update/install button while other updates are happening - we probably need something to handle the Ajax call responding with "maintenance mode".

#12 @mrwweb
9 years ago

It would be awesome if this overhaul laid the groundwork for or at least took into consideration #9757, allowing plugins/themes to be updated via zip upload.

#13 @hlashbrooke
9 years ago

I commented on the Make Core blog post, but thought I'd mention this here too:

Something that’s always stuck out in my mind is the fact that there are two separate actions for getting a new plugin running on your site: install & activate. In almost all cases, I would say that plugins are activated immediately after installing. To non-technical users, the differentiation probably doesn't even make all that much sense.

Could we rename the 'install' button and turn it into a 1-click 'activate' button? This would give the impression that WordPress and the plugin repo are all one cohesive system, instead of the segmented systems that they really are. It would eliminate one extra step and make the whole platform feel even more stable.

Last edited 9 years ago by hlashbrooke (previous) (diff)

This ticket was mentioned in IRC in #wordpress-dev by johnbillion_m. View the logs.


9 years ago

This ticket was mentioned in Slack in #core by melchoyce. View the logs.


9 years ago

This ticket was mentioned in Slack in #core by dd32. View the logs.


9 years ago

#17 @melchoyce
9 years ago

My notes from WordCamp San Francisco:

  • "Install & Activate" instead of just Install, then Activate
  • Label changes from Downloading… to Installing… to Activating… to show some progression when downloading something big/slow
  • Design alert styling (will attach next)
  • Mock up ftp creds screen w/ explanatory text that is similar to the modal you get when you're logged out
    • "To perform the requested action, WordPress needs to access your web server."
    • Hostname (localhost, yoursite.com)
    • Username
    • Password
      • Help text: "This password will not be stored on the server."
    • Public/private key
      • "Enter the location on the server where the keys are located. If a passphrase is needed, enter that in the password field above."
    • Radio buttons: ftp/ftps(ssl)/ssh
    • Submit button
  • Mock up what it looks like on the add new themes page
    • Also try updating mockup from the theme detail modal

This ticket was mentioned in Slack in #core by drew. View the logs.


9 years ago

This ticket was mentioned in Slack in #core by drew. View the logs.


9 years ago

#20 follow-up: @melchoyce
9 years ago

After some back and forth with Helen and Michael Arestad, I've mocked up a design (plugin-ftp-2.jpg) for when someone needs to provide FTP credentials before the install can happen.

#21 @johnbillion
9 years ago

  • Milestone changed from 4.1 to Future Release
  • Priority changed from high to normal

#22 @johnbillion
9 years ago

  • Version trunk deleted

#23 @ocean90
9 years ago

#30901 was marked as a duplicate.

@pento
9 years ago

#24 @pento
9 years ago

  • Milestone changed from Future Release to 4.2

In 29820.3.diff, you can now update from plugin cards, too!

(Yeah, I know I copy/pasted some strings, and put some plugin card CSS in list-tables.css. It's Friday afternoon.)

This ticket was mentioned in Slack in #core by drew. View the logs.


9 years ago

@pento
9 years ago

#26 @pento
9 years ago

29820.4.diff adds support for installing (and silently activating) from the plugin install screen.

A few notes:

  • It's mighty ugly. The button icons need better alignment, and we need a better icon for installing (it currently uses the updating icon).
  • It doesn't give any feedback that the plugin has been activated, as well. Given that users are used to having to click "Activate", we need a way to let them know it's been done for them.
  • It'll crash and burn if the plugin fatals on activation. To fix this, we can potentially use wp_remote_get() to fake the iframe that we used to activate plugins in.

I also really like the idea of plugins being able to define a post-activation action, perhaps as a button text and link - many plugins require configuration after activation, so a link to a config screen would be appropriate here.

#27 @DrewAPicture
9 years ago

  • Priority changed from normal to high

#28 @lgladdy
9 years ago

On the subject of a defined post-activation action - it's a feature I've wanted for a while!

I think it should be probably be "Configure" which can then be easily localised.

I think it would make sense to support that in the standard plugin header information, something like "Configure URL: options-general.php?page=googleanalytics"

This ticket was mentioned in Slack in #core by pento. View the logs.


9 years ago

#30 @obenland
9 years ago

For updates in Installed Plugins: After some time have the <code>Updated!</code> message disappear and the update the row's background color.

#31 @aercolino
9 years ago

What do you think about supporting automatic backups upon automatic updates?

Four days ago I opened #31138 (Backup of a plugin / theme directory) and attached a patch example, hoping that such a basic feature could find its way into the update flow.

Without automatic backups, there is no way to do anything about user's customizations of plugin / theme files.

Customizations are expected because we provide the plugin-editor.php and theme-editor.php pages to do exactly that. It's not safe to delete our stuff without making a backup before. It wasn't so with a manual update, it shouldn't be so with an automatic update.

@lgladdy
9 years ago

Patch 5 with post-activation configuration URL support

#32 @lgladdy
9 years ago

Okay! attachment:29820.5.diff provides a couple of fixed for little graphical position issues on the buttons and a first stab at adding support for plugins to provide a configuration URL, which turns the "Installed" button into a "Configure Now" button after installation, if a "Configuration URI" is defined in the plugin header.

For example:

/*
Plugin Name: Block Pinterest
Plugin URI: http://wordpress.org/extend/plugins/block-pinterest/
Description: Adds the required meta tags to stop your blog and image content appearing on Pinterest
Author: Liam Gladdy
Configuration URI: wp-admin/plugins.php
Version: 1.0.4
Author URI: http://www.twitter.com/lgladdy
*/

The configuration URI is always relative to the site root, and if you don't add a preceding forward slash, it's automatically added (so in the example above, it becomes /wp-admin/plugins.php)

If you want to test this, you can search for my "Block Pinterest" plugin and install it.

The green tick with "Configure Now" works pretty well I think - and we should consider adding the same tick and "configure" button when you see the refresh the page and see the disabled "Installed" button that is outside the AJAX updating code.

One final note: This is my first ever patch, so hopefully I did everything right! Let me know if not :)

Last edited 9 years ago by lgladdy (previous) (diff)

#33 follow-up: @dd32
9 years ago

Configuration URI: wp-admin/plugins.php

I don't think we'll be able to support this using a plugin header, as things such as Multisite get in the way.
A better route is probably just a filter that can be hooked onto to return a full URI.

#34 in reply to: ↑ 33 @lgladdy
9 years ago

Replying to dd32:

Configuration URI: wp-admin/plugins.php

I don't think we'll be able to support this using a plugin header, as things such as Multisite get in the way.
A better route is probably just a filter that can be hooked onto to return a full URI.

There isn't a way to do a scoped filter specific to one plugin right? So could we do something like a "get_configuration_url" filter with an array passed in that all plugins respond to and add their plugin name slug as a key and the URL as the value?

#35 @dd32
9 years ago

There isn't a way to do a scoped filter specific to one plugin

Currently we do something like this for activate hooks/etc (although we have a function to wrap these for activation hooks)

 $plugin = plugin_basename( $filename );
 $link = apply_filters( 'configure_link_' . $plugin, false, $arg2 );

which would result in a filter name of configure_link_plugin-slug/plugin.php.

@lgladdy
9 years ago

#36 @lgladdy
9 years ago

  • Summary changed from Smooth installation and updating of plugins and themes to re

attachment:29820.6.diff​ changes from a header parameter to a call back as per comment:35

It also removes the click handlers once a plugin has been installed which stops you being able to install a plugin twice.

The syntax is exactly as @dd32 described inside your plugin file:

$plugin_slug = plugin_basename( __FILE__ );
add_filter( 'configure_link_' . $plugin_slug, 'plugin_filter_configurl_function', 10, 1);

function plugin_filter_configurl_function( $link ) {
  return '/wp-admin/plugins.php';
}

Given register_activation_hook exists, do you think we should create a function called register_configuration_link too to abstract the need to do the plugin_basename stuff?

#37 @lgladdy
9 years ago

  • Summary changed from re to Smooth installation and updating of plugins and themes

Whoops, sorry about the summary change.

#38 @pbearne
9 years ago

This might be out of scope!
But can we make the search on the plugin listing page and the search on the install page return the same set of results.

The number of times I search on the install page when trying to install a plugin is embarrassing :-)

I do realize that we will need to handle the plugin functions in the results but that do-able

Paul

@ericlewis
9 years ago

#39 follow-ups: @ericlewis
9 years ago

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 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.
Last edited 9 years ago by ericlewis (previous) (diff)

#40 in reply to: ↑ 39 @pento
9 years ago

Nice work, @ericlewis!

Replying to ericlewis:

  • Think we should move the queue checker to the response callback handlers rather than on an interval.

Agreed. I originally did it with an interval because I was only using the success/error callbacks, so it could die. Using the complete callback removes the need for it.

#41 in reply to: ↑ 39 @adamsilverstein
9 years ago

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 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 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.

#42 in reply to: ↑ 39 ; follow-up: @lgladdy
9 years ago

Replying to ericlewis:

In attachment:29820.7.diff:

  • 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 lgladdy brought up earlier.

Seems you removed all the configuration URL code I added in patch 6 - was that intentional?

I still think we should support that - it would replace the need for plugins to do automatic redirects. That said, we obviously need to handle activations that redirect automatically already for BC - can we catch a wp_redirect nicely and treat that the same as a configuration URL?

I think auto-activation on install is still a sensible thing for the vast majority of cases.

Last edited 9 years ago by lgladdy (previous) (diff)

#43 in reply to: ↑ 42 @ericlewis
9 years ago

Replying to lgladdy:

Seems you removed all the configuration URL code I added in patch 6 - was that intentional?

Sorry, forgot to mention that. To recap, the use-case is that plugins want to drive users to another page after the plugin is activated. E.g. BuddyPress, BBPress, and many other plugins have "About" pages, which they redirect to on their plugin activation hook. Your suggestion is that other plugins may have a "configuration" page, to drive the user to choose settings for the plugin. This works fine when plugin activation happens on a page-reloading form submission, but now that we're installing and activating plugins via AJAX and keeping the user on the plugin install page, we need to decide what paths plugins should be able to opt into after the plugin is activated.

I didn't integrate that into the primary patch because I think we need more discussion here. Relatedly, I don't think supporting that use-case needs to happen in the first commit for this feature - it can happen in a follow-up ticket/effort. We should commit the MVP to trunk soon, and then iterate quickly.

We should gather a list of which plugins are doing something in this regard - feel free to add-on use cases and real-world examples here. To start that list:

  • Plugins that redirect to an About page on activation. Plugins doing this: BBPress, BuddyPress

This ticket was mentioned in Slack in #core by pento. View the logs.


9 years ago

#45 @adamsilverstein
9 years ago

29820.8.diff builds on 29820.7.diff:

  • add sanitize_key to all use of $_POST
  • remove the update class from the theme-check row after the update succeeds (I think this fixes the 'red background' issue Eric mentions, although I don't see a red background?)
  • call wp.updates.queueChecker on success for updates and installs, rather than polling

@DrewAPicture
9 years ago

Code style + escaping

#46 @DrewAPicture
9 years ago

29820.9.diff:

  • Fixes some code style
  • Escapes various attributes

#47 @pento
9 years ago

In 31333:

Shiny Updates: Add ajax-y updates to the plugin list page, and ajax-y updates and installs to the plugin card page.

This also includes JS architecture that can be expanded to support theme, core and language pack updates.

Props pento, ericlewis, lgladdy, adamsilverstein, DrewAPicture

See #29820

#48 @pento
9 years ago

We're doing it live, people! Thanks to everyone who's contributed so far. :-)

There are things left to do, here's the list I've jotted down:

Features TODO:

  • Add FTP support, based on @melchoyce's notes/mockups from earlier in this ticket.
  • Update themes from themes.php
  • Install themes from theme-install.php
  • Updates from update-core.php
  • A one-click-to-update-everything button for update-core.php. This would need to do things is a particular order:
    • Update all available themes/plugins
    • Update core
    • Check for more plugin updates, then do them - in case there plugins incompatible with the old core version, but compatible with the new version
    • Update language packs
  • Post-activation actions

Things to make more betterer:

  • Figure out a nice way to show progress
  • Make sure we don’t activate plugins that cause PHP errors - the idea would be to use wp_remote_get() to do a fake iframe-like activation. This could also return a lump of JSON that the plugin wants us to know about (say, the settings page to link a "Configure" button to).

#49 @pento
9 years ago

In 31334:

Shiny Updates: Add capability checks to the ajax callbacks, to ensure the current user is allowed to install/update plugins.

See #29820

#50 @pento
9 years ago

In 31335:

Shiny Updates: If the current user is not allowed to install/update plugins, we should return a JSON error, so it can be used by the JS handlers.

See #29820

This ticket was mentioned in Slack in #core by lgladdy. View the logs.


9 years ago

#52 @afercia
9 years ago

Tried on two different machines, I get an error when *installing* a new plugin. The response I get actually shows this:

<br />
<b>Notice</b>:  Undefined property: stdClass::$version in <b>D:\sviluppo\wpsvn\src\wp-admin\includes\plugin-install.php</b> on line <b>309</b><br />
<br />
<b>Notice</b>:  Undefined property: stdClass::$version in <b>D:\sviluppo\wpsvn\src\wp-admin\includes\plugin-install.php</b> on line <b>311</b><br />
{"success":true,"data":{"install":"plugin","slug":"theme-check"}}

I get a JS alert "Installation failed", the button hangs on "Installing..." but after I refresh the page the new plugin is actually installed I guess cause the response is... successful :)

@lgladdy
9 years ago

Fixes @afercia's bug report in comment:52

#53 @lgladdy
9 years ago

We weren't passing in the version number we're installing from the plugins_api into the install_plugin function, fixed in attachment:29820.fix-for-comment-52.patch

@iseulde
9 years ago

#54 @iseulde
9 years ago

Please JSHint before committing, it's very difficult to test other patches like this. Added a patch above.

#55 @boonebgorges
9 years ago

In 31341:

jshint fixes for shiny updates JS.

As introduced in [31333].

Props iseulde.
See #29820.

#56 @pento
9 years ago

In 31345:

Shiny Updates: Fix a PHP warning when installing new plugins.

Props lgladdy for the initial patch.

See #29820

#57 @pento
9 years ago

Also TODO, via @nacin:

Not sure who wrote it, but the XHR bits are overly complicated.

Bring in wp-util.js and use wp.ajax.post with .done(), .fail(), and .always().

Those RequestComplete, Error, and Success named functions can just become closures, probably. (Or not, if there's a desire to leave them like that for testability.)

#58 @afercia
9 years ago

Please consider handling broken plugins or plugins that output something during automatic activation, for example:

  • go in the "Beta Testing" tab and install "Customize Partial Refresh"
  • the plugin throws an Exception during activation (see the response in your browser dev-tools)
  • so, no JSON response: just text/html and no responseJSON object
  • you get a JS alert "Installation failed" and the button hangs on "Installing..."
  • refresh the page, the plugin is actually installed but not activated

For reference, the error details:

Fatal error: Uncaught exception 'Exception' with message 'Class not located within a directory tree containing 'plugins': 
/src/wp-content/plugins/customize-partial-refresh/php/class-wp-customize-partial-refresh-plugin.php' in /src/wp-content/plugins/customize-partial-refresh/php/class-wp-customize-partial-refresh-plugin.php:92 
Stack trace: #0 /src/wp-content/plugins/customize-partial-refresh/php/class-wp-customize-partial-refresh-plugin.php(31): WP_Customize_Partial_Refresh_Plugin->locate_plugin() 
#1 /src/wp-content/plugins/customize-partial-refresh/customize-partial-refresh.php(33): WP_Customize_Partial_Refresh_Plugin->__construct() 
#2 /src/wp-admin/includes/plugin.php(542): include_once({mycheckoutpath}) 
#3 /src/wp-admin/includes/ajax-actions.php(2872): activate_plugin('customize-parti...') 
#4 [internal function]: wp_ajax_install_plugin('') 
#5 /src/wp-includes/plugin.php(496): call_user_func_array(' in /src/wp-content/plugins/customize-partial-refresh/php/class-wp-customize-partial-refresh-plugin.php on line 92

Btw the point is there's always a chance users will install a broken plugin, maybe the automatic activation should be reconsidered or should handle this kind of errors.

This ticket was mentioned in Slack in #core by eric. View the logs.


9 years ago

#60 in reply to: ↑ 20 @ericlewis
9 years ago

Replying to melchoyce:

After some back and forth with Helen and Michael Arestad, I've mocked up a design (plugin-ftp-2.jpg) for when someone needs to provide FTP credentials before the install can happen.

I'm curious, what was the reasoning for placement of the credential request form inside the plugin card?

Regarding the credentials request, we could, after the first credential request, store credentials locally in a JavaScript variable. That way credentials only need to be entered once per page load, as we can bundle them with following AJAX install requests.

#61 follow-up: @ericlewis
9 years ago

In attachment:29820-current-theme-update-flow.mp4, a reminder of the existing theme update workflow. User must click into Details modal, clicks update link. We could surface an update button on the theme card at the list view (mock-up in attachment:29820-new-theme-update-button.png), so the user doesn't need to drill down into the details modal to update. This would also bring closer parity with the install/upgrade experience for plugin cards.

#62 in reply to: ↑ 61 @pento
9 years ago

Replying to ericlewis:

We could surface an update button on the theme card at the list view (mock-up in attachment:29820-new-theme-update-button.png), so the user doesn't need to drill down into the details modal to update. This would also bring closer parity with the install/upgrade experience for plugin cards.

I like this plan. :-)

#63 @pento
9 years ago

In 31409:

Shiny Updates: Replace $.post() calls with wp.ajax.post(), and clean up a bunch of the now unnecessary code.

See #29820

#64 @pento
9 years ago

Reported by @ryan, via Slack:

I had plugins.php idling with Jetpack showing an update available. Came back around after doing other stuff for a awhile, clicked Update Now, and noop. Click, click, nothing. I reloaded plugins.php, and Jetpack was already on the latest version. Speculation: Background update of the plugin behind its back caused Shiny Updates to noop? Didn't capture a vizrec, alas.

This ticket was mentioned in Slack in #buddypress by jjj. View the logs.


9 years ago

This ticket was mentioned in Slack in #core by pento. View the logs.


9 years ago

#67 @kraftbj
9 years ago

I tried to duplicate https://core.trac.wordpress.org/ticket/29820#comment:64 (Background Updates causes failure).

My first method:
Two browser windows, both on plugins.php.
Update in one to simulate a background update.
Attempted to upgrade in the original.
The original returned Success. No indication that it was already upgraded, but no "problem" either.

Second:
Left a window open a long time on plugins.php
Clicked Update Now
Nothing changed at all on the line item, but admin-ajax.php was hit with the update command, returned with success:true.

Before and after looks like: https://cloudup.com/c3cArkap-Y4
admin-ajax.php was pinged with

data: {update: "plugin", plugin: "always-use-jetpack-open-graph/always-use-jetpack-open-graph.php",…}
plugin: "always-use-jetpack-open-graph/always-use-jetpack-open-graph.php"
slug: "always-use-jetpack-open-graph"
update: "plugin"

response: success: true

#68 @DavidAnderson
9 years ago

Concerning the issues of what happens after installation and activation and redirection, one issue that will confuse users is that if there is no redirection, then you don't get to see anything added by the plugin to your dashboard until you reload the dashboard.

e.g. Plugin Foo adds a new menu in "Tools -> Frobnosticator". But, it's not there until the page reloads. Result: unless the user realises this, he may be confused; click around a bit, and then see it is there after all. Files issue in support forum, "Hi, after installing + activating your plugin, the Tools -> Frobnosticator menu entry was not there... I clicked around a bit, then it was. Not sure what caused that. You'll want to get that fixed in your plugin!".

#69 @ocean90
9 years ago

In 31465:

grunt autoprefixer for [31333].

see ##29820.

#70 @ericlewis
9 years ago

I'd like to suggest we do a modal takeover for a credential request. Requesting credentials will need to take place in screens that have strikingly different layouts (List Table screens, Add Plugins screen, Add Themes screen, Update Core screen). A modal takeover is layout-independent, and doesn't go against the UX. Rough prototype in attachment:'Screen Shot 2015-02-15 at 4.09.25 PM.png'.

Last edited 9 years ago by ericlewis (previous) (diff)

#71 @jdgrimes
9 years ago

I just got the following error several times:

[17-Feb-2015 22:56:01 UTC] PHP Notice:  Undefined index: plugin in /Users/johngrimes/svn/wordpress/trunk/src/wp-admin/includes/update.php on line 279
[17-Feb-2015 22:56:01 UTC] PHP Stack trace:
[17-Feb-2015 22:56:01 UTC] PHP   1. {main}() /Users/johngrimes/svn/wordpress/trunk/src/wp-admin/plugins.php:0
[17-Feb-2015 22:56:01 UTC] PHP   2. WP_List_Table->display() /Users/johngrimes/svn/wordpress/trunk/src/wp-admin/plugins.php:470
[17-Feb-2015 22:56:01 UTC] PHP   3. WP_List_Table->display_rows_or_placeholder() /Users/johngrimes/svn/wordpress/trunk/src/wp-admin/includes/class-wp-list-table.php:952
[17-Feb-2015 22:56:01 UTC] PHP   4. WP_Plugins_List_Table->display_rows() /Users/johngrimes/svn/wordpress/trunk/src/wp-admin/includes/class-wp-list-table.php:1015
[17-Feb-2015 22:56:01 UTC] PHP   5. WP_Plugins_List_Table->single_row() /Users/johngrimes/svn/wordpress/trunk/src/wp-admin/includes/class-wp-plugins-list-table.php:374
[17-Feb-2015 22:56:01 UTC] PHP   6. do_action() /Users/johngrimes/svn/wordpress/trunk/src/wp-admin/includes/class-wp-plugins-list-table.php:632
[17-Feb-2015 22:56:01 UTC] PHP   7. call_user_func_array() /Users/johngrimes/svn/wordpress/trunk/src/wp-includes/plugin.php:496
[17-Feb-2015 22:56:01 UTC] PHP   8. wp_plugin_update_row() /Users/johngrimes/svn/wordpress/trunk/src/wp-includes/plugin.php:496

I'm not sure how to reproduce.

I believe it was introduced in [31333] (https://core.trac.wordpress.org/changeset/31333#file5). I'm not sure why $plugin_data['plugin'] is used instead of $file.

#72 follow-up: @afragen
9 years ago

@jdgrimes are you using some other plugin that also has auto updating? I ran across this error in in my plugin and have fixed it. It may not be a core error.

#73 in reply to: ↑ 72 @jdgrimes
9 years ago

Replying to afragen:

@jdgrimes are you using some other plugin that also has auto updating? I ran across this error in in my plugin and have fixed it. It may not be a core error.

I don't think so. Anyway, I see no reason to rely on $plugin_data['plugin'] when $file is guaranteed as far as I can tell.

#74 @dd32
9 years ago

#31431 was marked as a duplicate.

#75 @afercia
9 years ago

Noting here a feedback from the accessibility testers group: there's no feedback about the activation of the plugin, we're just saying "installed", maybe worth considering a better message string for wp.a11y.speak and maybe also some check about successful/unsuccessful activation.

This ticket was mentioned in Slack in #core by pento. View the logs.


9 years ago

#77 @pento
9 years ago

  • Keywords shiny-updates added; ux-feedback removed

The remaining tasks on this ticket have been split into individual tickets under the shiny-updates keyword.

Per discussion after the dev chat today, these are our priorty tasks:

  • FTP support: #31528
  • Update themes from themes.php: #31529
  • Install themes from theme-install.php: #31530
  • All updates from update-core.php: #31531
  • Don't activate plugins with PHP errors: #31532

And we have some things that we'll get to if we have time, otherwise they can wait until a future release:

  • One-click update on update-core.php: #31533
  • Language install on options-general.php: #31534
  • Store FTP credentials: #31535

If there's something here you'd like to tackle, please assign the relevant ticket to yourself.

#78 @DrewAPicture
9 years ago

  • Milestone changed from 4.2 to Future Release
  • Type changed from task (blessed) to enhancement

It pains me to say that despite the recent surge in activity we aren't going to be able to get this one over the finish line for 4.2. We needed to have the big pieces done in time for Beta 1 and it just isn't going to happen. Good effort, folks.

Maybe we can get it done in 4.3.

#79 @DrewAPicture
9 years ago

  • Priority changed from high to normal

#80 @DrewAPicture
9 years ago

Best I can tell, we're going to need to revert [31333], [31334], and [31335].

#81 @DrewAPicture
9 years ago

  • Milestone changed from Future Release to 4.2
  • Type changed from enhancement to task (blessed)

Consider my hand slapped. Let's talk about it at the devchat tomorrow and decide if anything is salvageable.

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


9 years ago

@jorbin
9 years ago

#83 @jorbin
9 years ago

The above patch starts splitting the file credential checks into a standalone function while also turning fancy updates off when we need to request filesystem credentials. This is only partially tested right now. A list of things that need to be tested:

Fancy updates/installs for each method.
Classic updates/installs for each method (likely easiest to use themes for this)
What happens when stored credentials are wrong? (for all of the permutations of the two of the above scenarios)
What happens when passed in credentials are wrong? (for all of the permutations of the two above scenarios)

For testing, I've been using the core-control plugin to force a method.

In order to have a local FTP server, I'm using VVV and running the following command to install and activate an FTP server:
sudo apt-get install vsftpd && sudo sed -i -e "s/\#write_enable=YES/write_enable=YES/" /etc/vsftpd.conf && sudo restart vsftpd
VVV has the username vagrant and the password of vagrant available by default.

This ticket was mentioned in Slack in #core by jorbin. View the logs.


9 years ago

#85 @jipmoors
9 years ago

Also made a patch for the specific request_filesystem_credentials functionality split, see #31616
A slightly different approach though.

This ticket was mentioned in Slack in #core by jorbin. View the logs.


9 years ago

This ticket was mentioned in Slack in #buddypress by netweb. View the logs.


9 years ago

@jorbin
9 years ago

#88 @jorbin
9 years ago

In 31897:

Remove Shiny Plugin Installs

See #31773, #29820

#89 @jorbin
9 years ago

  • Keywords close added

I think at this point, everything is spiked out into new tickets. I believe we can close this against 4.2 and continue anything remaining in those tickets.

#90 @DrewAPicture
9 years ago

  • Keywords close removed
  • Resolution set to fixed
  • Status changed from new to closed

#91 @jorbin
9 years ago

In 31900:

More clean up from removal of Shiny Plugin Installs

See #31773, #29820
Unprops Jorbin, Pento

#92 @jorbin
9 years ago

In 31901:

Remove Shiny Plugin Install strings

See #31773, #29820

#93 @ocean90
9 years ago

In 31904:

End "Update failed" with a full stop.

see #29820.

#94 @DavidAnderson
9 years ago

I've created #31819 for an issue with allowing plugins to get involved with the flow - by allowing them to interact with the locking used by shiny updates.

#95 follow-up: @mindctrl
9 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

There's no way to close the Connection Information modal that pops up asking for credentials when required. It would be great to have that.

#96 in reply to: ↑ 95 @jorbin
9 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

Replying to mindctrl:

There's no way to close the Connection Information modal that pops up asking for credentials when required. It would be great to have that.

This was added in [31949]. There is a cancel button and you can also use the esc key and click on the non modal part of the screen.

#97 @jorbin
9 years ago

In 32053:

Remove Shiny Bulk Updates

Bulk updates don't need to be ajaxified so let's revert.

See #31770, #29820,

Note: See TracTickets for help on using tickets.