Add "update_version" field to the output from `wp theme get [theme]` and `wp plugin get [plugin]`

[baizmandesign]

Feature Request

• Yes, I reviewed the contribution guidelines.

Describe your use case and the problem you are facing

I'd like to see the "update_version" field in the output from wp theme get [theme] and wp plugin get [plugin].

This would bring parity to the wp theme list and wp plugin list commands. (Rather, the default doesn't show the "update_version" field for either command, but the field can be added via the --fields parameter.)

Unlike the list subcommands, I think the default output should include the "update_version" for the get subcommands, if there's an update available.

Here's what I see today for the Astra theme:

 $ wp theme get astra                   
+----------------+-------------------------------------------------------------+
| Field          | Value                                                       |
+----------------+-------------------------------------------------------------+
| name           | Astra                                                       |
| title          | Astra                                                       |
| version        | 4.11.8                                                      |
| status         | parent                                                      |
| parent_theme   |                                                             |
| template_dir   | /Users/saul/Documents/apache_sites/lifetimearts.test/wp-con |
|                | tent/themes/astra                                           |
| stylesheet_dir | /Users/saul/Documents/apache_sites/lifetimearts.test/wp-con |
|                | tent/themes/astra                                           |
| template       | astra                                                       |
| stylesheet     | astra                                                       |
| screenshot     | screenshot.jpg                                              |
| description    | The Astra WordPress theme is lightning-fast ...             |
| author         | <a href="https://wpastra.com/about/?utm_source=theme_previe |
|                | w&#038;utm_medium=author_link&#038;utm_campaign=astra_theme |
|                | ">Brainstorm Force</a>                                      |
| tags           | ["custom-menu","custom-logo","entertainment","one-column"," |
|                | two-columns","left-sidebar","e-commerce","right-sidebar","c |
|                | ustom-colors","editor-style","featured-images","full-width- |
|                | template","microformats","post-formats","rtl-language-suppo |
|                | rt","theme-options","threaded-comments","translation-ready" |
|                | ,"blog"]                                                    |
| theme_root     | /Users/saul/Documents/apache_sites/lifetimearts.test/wp-con |
|                | tent/themes                                                 |
| theme_root_uri | http://lifetimearts.test/wp-content/themes                  |
+----------------+-------------------------------------------------------------+

Here's what I'd like to see:

 $ wp theme get astra                   
+----------------+-------------------------------------------------------------+
| Field          | Value                                                       |
+----------------+-------------------------------------------------------------+
| name           | Astra                                                       |
| title          | Astra                                                       |
| version        | 4.11.8                                                      |
| update_version | 4.11.9                                                      |
| status         | parent                                                      |
...
+----------------+-------------------------------------------------------------+

Even if the output doesn't contain the "update_version" field by default, it would be nice if it could accept the field via the --fields parameter, which it currently cannot.

[swissspidy]

Thanks for your feature request!

The get commands currently only show data that's available locally, i.e. from the plugin header, whereas list retrieves update info, auto_update state, wporg_status, and much more. It sounds reasonable to get them aligned. There might be an opportunity to bring parity between the two commands while reusing the same code underneath. Sounds like an interesting idea to explore 👍

[baizmandesign]

@swissspidy Thanks for your response! I didn't realize the two subcommands were querying different areas of the WordPress ecosystem. (I wonder why that is.) If you'd like to assign this issue to me, I'll try to take a crack at this in the coming weeks.

[swissspidy]

We don't normally do assignments, but feel free to take a stab at it :)

[baizmandesign]

@swissspidy Works for me!

[baizmandesign]

@swissspidy A question for you. I'm reviewing the code responsible for both the list and get subcommands, and if part of the motivation behind this issue is bringing parity to the subcommands, should the non-standard orientation of the output be addressed? To be clearer, for most WP CLI commands, the first row of tabular output contains the field headings. The plugin and theme get subcommands are the only two off the top of my head whose tabular output contains the field headings in the first column. Do we wish to change this behavior, or is that a considered a breaking change?

Put another way, why is the output for the get subcommand different from most others, and is this difference desirable to retain? (Are there any other commands whose output is "rotated"?)

[swissspidy]

Put another way, why is the output for the get subcommand different from most others, and is this difference desirable to retain? (Are there any other commands whose output is "rotated"?)

Good question. Not sure to be honest, I haven't been around that long :-) But I don't think we should change it, as that would be a breaking change.

[baizmandesign]

@swissspidy I'm almost tempted to add a flag, like --transposed, to display the subcommand's output like all of the other subcommands. At any rate, we'll keep the default display as is, odd as it may be.