Feature: "plugin update" should identify plugins where the server response indicates automatic update

[DavidAnderson684]

Feature Request

• Yes, I reviewed the contribution guidelines.

Describe your use case and the problem you are facing

Background: when wordpress.org (or a third-party server) is asked about updates for a plugin, the response includes a flag that indicates whether an automatic update of the plugin should be carried out. (This is not to be confused with the WordPress saved settings for automatically updating plugins). wordpress.org use this flag to push automatic updates in the case of large plugins with security vulnerabilities (there is code in WordPress core to recognise it and respond to it). When this flag is set, the response indicates the recommended update (which is not necessarily the latest - sometimes, the plugin may have multiple updates available which update the "minor" version series, so that things aren't broken by an undesired major update; e.g. there are releases of Foo 1.3.2, 1.2.4 and 1.1.5 which contain only the fixes for the security issues in 1.3.1, 1.2.3 and 1.1.4 ).

Use case: I wish to update only plugins which have this flag set, and update to the indicated version. My WordPress install does not update automatically because it is locked down to prevent WordPress self-modifying plugin/theme files when within an "HTTP" context. But those restrictions are not active in a "CLI" context, and there, WordPress can self-modify.

Describe the solution you'd like

1. Add a --auto-update-indicated switch to https://developer.wordpress.org/cli/commands/plugin/update/ to indicate only to update plugins with this flag set (and in this case, the default value of --version should be the version indicated by the server response, not the otherwise default of the latest release available).

2. Also perhaps include the "auto update indicated" information in the output rendered.

[danielbachhuber]

Thanks for the suggestion, @DavidAnderson684.

If this is data that WordPress.org provides, adding a flag in the manner you described seems reasonable.

[jcvignoli]

Hi @danielbachhuber
Should we expect such a feature?

[danielbachhuber]

@jcvignoli I'm open to a pull request! Feel free to submit one, if you'd like. Here is some guidance on our pull request best practices.

[jcvignoli]

@danielbachhuber Unfortunately, I'm not really a dev :)