Hi @ziegenberg,
thank you for opening the pull-request, that's a good idea to support the JSON format.

I wonder though whether we should provide the same data in both the tabular and JSON output, mainly now thinking about the comment field in the JSON output. That is not consistent with what the user sees in the table. Can we keep the same behaviour as in the table view where it's all within the Status field, and keep the labels in the same style, i.e. plugin/core/status/version?

What do you think about that?

I will also suggest a few minor code-style tweaks that you can bulk-commit directly from Github's interface.

Hi @michalkleiner,

I incorporated the proposed style changes (is there an automatic style checker I missed?).

Regarding the differences in tabular and JSON output: On the one side I didn't want to change the table headers for the tabular output and on the other side Core or optional? isn't a good key for a JSON field, so I opted for simple keys for the JSON output (plugin, core, activated, version) which describe the data most accurately. I also used boolean data fields, cause they are easy to use with automation tools and the JSON output will most likely be used with such tools. I, for example, want to use the new JSON output to make life with Ansible Automation and my Matomo Ansible role easier. Mixing error information with data in fields is rather a handicap in this regard, so I opted for the comment field.

If you like, I can extend the description of the new --json option and the description of the plugin:list command to further explain the data output and the meaning of the columns and respectively the fields.

Thanks @ziegenberg, you didn't miss a checker, we are slowly implementing CS changes and in the end there will be one.
Regarding the JSON format and the differences to the tabular output, I take your point and reasoning. I provided my feedback with the view that it can be addressed either at the generation point or when processing the JSON output at the other end, but I agree that for automated and/or scripted processing boolean values are easier to work with than deciphering the values from the text output, so all good on that part.

With that, I'm happy to approve this, I'd ask @sgiehl for his opinion and then we might be able to merge that in.

One point I'd make is that in the long-term, we might want to add a --json switch to other commands that produce tabular output and there it would be basically about the output format, but the data would be the same, which is why I also inclined towards having the data the same.
Alternatively, we could update the tabular view of the plugin:list output to have the same boolean columns and the comment column. I'd be open to that. What do you think about that, @sgiehl?

Personally I wouldn't see it as part of a console command to support different return types at all. That is what our API is meant for and is able to handle automatically. So if something is needed in different formats, I would suggest to add an API method for that instead.

Aside from the changes discussed above, I pulled up the static function wrapInTag from \Piwik\Plugins\CoreAdminHome\Commands\ConfigGet and respectively \Piwik\Plugins\CoreAdminHome\Commands\ConfigSet to Piwik\Plugin\ConsoleCommand to make it available to other Commands as well. I found several places in other commands where wrapInTag could be used. Are you interested in another PR?

Having low-level access to certain information makes automation very easy and convenient. The console command eg. already provides config:get and it has a --format option, which formats the output as json, yaml or text; the default is json.

I rebased onto the current 5.x-dev