Skip to content

Conversation

Copy link
Contributor

Copilot AI commented Feb 1, 2026

wp plugin update --all and wp theme update --all provide no indication of which extension is currently being updated, making it difficult to track progress or identify problematic updates.

Changes

  • Added ExtensionUpgraderSkin - Extends base UpgraderSkin with before() method that outputs "Updating {name}..." before each update operation

    • Handles plugins via $this->plugin_info['Name'] array
    • Handles themes via $this->theme_info->get('Name') WP_Theme object
    • Decodes HTML entities in extension names
  • Modified CommandWithUpgrade::get_upgrader() - Instantiates upgraders with ExtensionUpgraderSkin instead of default UpgraderSkin

    • Duplicates upgrader creation logic from Utils\get_upgrader() as skin must be passed to constructor
  • Added test coverage - Behat scenarios verify correct name display for both plugin and theme bulk updates

Example Output

Before:

Unpacking the package...
Installing the plugin...
Plugin updated successfully.
Success: Updated 2 of 2 plugins.

After:

Updating Health Check & Troubleshooting...
Unpacking the package...
Installing the plugin...
Plugin updated successfully.
Updating WordPress Importer...
Unpacking the package...
Installing the plugin...
Plugin updated successfully.
Success: Updated 2 of 2 plugins.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

  • api.wordpress.org
    • Triggering command: /usr/bin/curl curl -s REDACTED (dns block)
  • downloads.wordpress.org
    • Triggering command: /usr/bin/curl curl -sSfL REDACTED (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

Original prompt

This section details on the original issue you should resolve

<issue_title>wp plugin update all doesnt display info which plugin is being updated</issue_title>
<issue_description>The output for all plugins updated is always this:

Unpacking the package...
Installing the plugin...
Removing the old version of the plugin...
Plugin updated successfully.
Success: Installed 1 of 1 plugins.

Would be much more helpful if it at least said once which plugin it is updating in a separate line first.</issue_description>

Comments on the Issue (you are @copilot in this section)

@danielbachhuber > Would be much more helpful if it at least said once which plugin it is updating in a separate line first.

I agree!</comment_new>
<comment_new>@danielbachhuber
I think it would still be nice to indicate the plugin in the log output, e.g.:

$ wp plugin update --all
Enabling Maintenance mode...
Updating akismet
Downloading update from https://downloads.wordpress.org/plugin/akismet.3.1.11.zip...
Unpacking the update...
Installing the latest version...
Removing the old version of the plugin...
Plugin updated successfully.
Updating nginx-champuru
Downloading update from https://downloads.wordpress.org/plugin/nginx-champuru.3.2.0.zip...
Unpacking the update...
Installing the latest version...
Removing the old version of the plugin...
Plugin updated successfully.
Disabling Maintenance mode...
````</body></comment_new>
<comment_new><author>@swissspidy</author><body>
We should be able to override those strings simply by extending `Plugin_Upgrader` and overriding the `upgrade_strings()` / `install_strings()` methods.</body></comment_new>
<comment_new><author>@danielbachhuber</author><body>
@baizmandesign Thanks for diving into it!

> The previous comments say that we need to extend Plugin_Upgrader and over-ride upgrade_strings() and install_strings(). It was also necessary for me to over-ride the entire run() method of the Plugin_Upgrader class located in [wp-admin/includes/class-wp-upgrader.php](https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-admin/includes/class-wp-upgrader.php). While this worked, it introduced quite a bit of redundant code. Is there an approach that doesn't require so much duplication (~220 lines)?

Oh wow, that's a lot of code. We don't want to fork core that substantially for something relatively inconsequential like this.

What made it necessary to override the entire `run()` method?</body></comment_new>
<comment_new><author>@danielbachhuber</author><body>
@baizmandesign It looks like this `before()` method is called roughly when we'd like it to:

https://github.com/WordPress/wordpress-develop/blob/ee5142efbca11450e7befd202d37eba4660173c1/src/wp-admin/includes/class-wp-upgrader.php#L812

We can render whatever output we'd like in our custom `UpgraderSkin`:

https://github.com/wp-cli/wp-cli/blob/52751b1d1f8bdf0b47d38942ec199c7840ee1d85/php/WP_CLI/UpgraderSkin.php#L13

If that doesn't work for whatever reason, we could instead render some output on this filter:

https://github.com/WordPress/wordpress-develop/blob/ee5142efbca11450e7befd202d37eba4660173c1/src/wp-admin/includes/class-wp-upgrader.php#L796

I think both of these would be better than forking `run()`.</body></comment_new>
<comment_new><author>@danielbachhuber</author><body>
> The "Name" field is the closest thing to the slug I could find. Here's what some sample output looks like when updating two plugins:

I think this could be fine. Can you share all of the data that's in the array?



> It seems to be the case that all of the status messages that appear during the upgrade process are stored in the `$strings` property of the `Plugin_Upgrader` object. The text I'm outputting only lives in the `before()` method of the `UpgraderSkin` object. Should we add this text to the `$strings` property?

I don't fully grok the implications of this. Can you explain further?</body></comment_new>
<comment_new><author>@BrianHenryIE</author><body>
There's a few options here.

1. Your existing WIP, https://github.com/wp-cli/wp-cli/compare/main...baizmandesign:wp-cli:feature/plugin-update-info-261, needs to check `isset( $this->plugin_info )` because that array doesn't seem to be available during a plain `wp plugin install plugin-slug`, and decode the special characters from the string
2. That array will, for .org plugins, have a `PluginURI` field where the slug can be found with `preg_match('/https:\/\/wordpress.org\/plugins\/(.*?)\//', $input_line, $output_array);`
3. Open a patch for Core to pass the [Plugin_Upgrader::bulk_upgrade() `$options`](https://github.com/WordPress/WordPress/blob/797fa55a03c24ec85a5f28c629f1eaf257d9010c/wp-admin/includes/class-plugin-upgrader.php#L380-L396) array to [WP_Upgrader_Skin::before()](https://github.com/WordPress/WordPress/blob/797fa55a03c24ec85a5f28c629f1ea...

</details>



<!-- START COPILOT CODING AGENT SUFFIX -->

- Fixes wp-cli/extension-command#261

<!-- START COPILOT CODING AGENT TIPS -->
---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our [2 minute survey](https://gh.io/copilot-coding-agent-survey).

Copilot AI and others added 4 commits February 1, 2026 17:50
Co-authored-by: swissspidy <841956+swissspidy@users.noreply.github.com>
Co-authored-by: swissspidy <841956+swissspidy@users.noreply.github.com>
…update test

Co-authored-by: swissspidy <841956+swissspidy@users.noreply.github.com>
Co-authored-by: swissspidy <841956+swissspidy@users.noreply.github.com>
Copilot AI changed the title [WIP] Add display of plugin name during update Display extension names during bulk updates Feb 1, 2026
Copilot AI requested a review from swissspidy February 1, 2026 17:56
@codecov

This comment was marked as resolved.

@swissspidy swissspidy marked this pull request as ready for review February 3, 2026 14:18
@swissspidy swissspidy requested a review from a team as a code owner February 3, 2026 14:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

wp plugin update all doesnt display info which plugin is being updated

2 participants