Include additional column (field) "auto-updates" which can be on or off

[porg]

• See: wp-cli/ideas#171

Why this extra field?

• I would like to export the list of extensions with all their attributes:
  • Status: Active/inactive → ✅ This is already exported.
  • Auto updates: On / off → ❌ This info is not there explicitly!
  • There is a column update with the possible values none and available.
    • As I understand it, this expressed whether updates are available in the repository or not.
    • But there is no field (I am aware of) which tracks whether the site administrator set auto-updates on or off for a plugin.

I'd like the attribute "auto updates on/off" to be restored exactly during automatic re-installation

• If I had certain plugins frozen to a particular version with auto-update OFF, I would like them to get a different treatment during re-installation:
  • Plugin which had auto-update OFF, gets restored with wp plugin install pluginName --version=storedVersion
  • Plugin which had auto-update ON, gets restored with wp plugin install pluginName
    • which is either the storedVersion, if no newer version is available at the time of re-installation
    • or a newer version, if meanwhile available in the repo.

[Daniel Bachhuber]

Thanks for the suggestion!

Including the auto_update value in wp plugin list seems fine. Feel free to submit a pull request if you'd like. Here is some guidance on our pull request best practices, if it's helpful.

[porg]

Regarding pull request:

• Thanks for the trust in me
• But I'm a UX designer by trade.
  • Tech savvy enough to talk with you dev guys.
  • But I myself never got above amateur coding levels. 😉 And decided to keep it that way and concentrate on my strenghts.
• I hope though that my precise description helps to foster this baby to implementation.

[Daniel Bachhuber]

Sounds good!

[porg]

Forgot to say: As the extension-command repository concerns both the verbs plugin as well as theme:

• That extra column auto-update should be toggle-able for both $ wp plugin list and $ wp theme list.
• Workaround for now: $ wp theme auto-updates status --all. Ofc all in one table output would be most handy!

[porg]

1. @endriu84 great that you volunteered and implemented the proposal! Thanks!
2. The feature is yet not included in the nightly build.
   • I performed wp cli update --nightly and now have wp cli version WP-CLI 2.8.0-alpha-4d9bd04.
   • When I use wp plugin list --fields=name,status,version,update the output is exactly in that order, but when I add the new field auto_updates as the last field, or for that matter anywhere in that comma-delimited list, I get Error: Invalid field: auto_updates.
   • I tried all permutations of alternative spelling/notations auto[_-]updates? which all failed.
3. Sorry that my specification was not too clear on this: Intention was that the column auto updates is shown by default when using the list verb both for plugin and theme and only potentially toggled by selecting specific --fields. B/c I consider the auto updates part of the standard information henceforth.

• @danielbachhuber regarding backwards compatibility: Is the output of wp theme|plugin list without further options used anywhere programmatically (pipe out → pipe in) which would choke on the new column and/or the column order? If no then I think nothing stops us from printing that extra column by default. Usability wise its clearly better to include it by default.
• @ALL: For optimal readability I propose this default column order for both plugin and theme output, to serve this mental/reading flow:
  • --fields=name,status,version,update,auto_update
  • Which plugin/theme?
  • Do I use it? active, must-use, inactive.
    • For optimal readability it would ideally a very narrow column left of the name column, entitled "?" or "stat".
    • With the possible values A, M, I or √ ! x or 🟢 🟠 🔴. Or simply only A, M or √ ! or 🟢 🟠 and leaving inactive ones blank. Less visual noise! The emojis would be fine visually, but for programmatic processing pure ASCII is possibly safer I assume.
  • Which version do I have? → 1.2.3
  • Is there a newer version? If yes, which one? I propose to just show the new available version, e.g. 1.3 instead of the generic 'available'. If you agree but want to manage this in a separate issue, I could create a followup issue for this.
  • Does this update automatically? → If no but there's a (significantly) newer version available, then I know it is now a good time to check out the the changelog/blog of that plugin and decide whether my update that I postponed on purpose for good reasons, is now finally possible. If yes, I'm assured. If yet but the "updates" column shows a higher version number, I know that with the next cronjob it will get updated or I can trigger an update now manually, if needed.

[Daniel Bachhuber]

The feature is yet not included in the nightly build.

@porg Sorry about that! We hadn't tagged a release yet. I just did, so it will show up in the nightly in the next day or two.

There are a lot of additional fields that could be displayed (and are displayed in the admin). I think we'll keep the field list as it is for now. It's easy enough to use the --fields= parameter to get exactly what you want.

[porg]

Please reconsider for these reasons:

• The overarching idea for this feature was: wp-cli/ideas/issues/171
  • Backing up up your "theme/plugin" manifest file (similar as in package managers) should be as easy/complete as possible so that a "1:1" restore from this is easily possible with the restore counterpart.
  • The restore counterpart would be simply a theme/plugin install verb which takes such a CSV manifest file and reinstall exactly the same themes and plugins.
    • Those with auto-update get the most recent version at the time of execution, those with auto-update OFF get the exact same version as was installed.
    • That functionality is yet not there, but with some xargs and some piping to the theme/plugin verbs possible.
    • But for that "restore" scenario to work, the manifest backup should work as seamless and easy as possible.

Please give it a thought!