Development Build: Provide structure to auto-install plugins

[kraftbj]

When doing local development, I never use a completely blank version of WordPress. I always install a plugin like Query Monitor to help me debug and monitor development on the fly.

Additionally, for some themes and plugin development, a developer may always or often need particular plugins installed.

I propose automatically installing Query Monitor (FYI @johnbillion ) for Core development while also creating a structure to allow other developers using this box for other types of work to define as an environmental variable other options.

I suggest only installing, not activating, to ensure that the running code is intentional as compared to the pristine environment.

In our Travis config, for tests, we should not have anything different than a production build, so a false variable will disable anything from being installed.

For other uses, a comma-separated list would provide a way to install multiple plugins.

cc: @pento

[kraftbj]

First pass.

[johnbillion]

Related / list of other plugins that could be installed by default: #42879

[afragen]

There are simple methods of doing this outside of core too. I do this with the ​WP Debugging plugin. I use a ​framework of my own, similar to TGMPA, to optionally, or not, add plugins.

The solution in this case means creating your own _plugins I use for development_ plugin and adding those plugins to the JSON.

[kraftbj]

@afragen Absolutely. Definitely ways to do this outside of Core to various degrees. The motivation behind this is the local development build is relatively new to Core and, as things in Core tend to be used as a model or starting point for others, looking at allowing that environment to be flexible enough that someone can pick it up to use it generally if they don't have a preferred environment already or have specific requirements that make a generalized solution appropriate.

[afragen]

Replying to kraftbj:

@afragen Absolutely. Definitely ways to do this outside of Core to various degrees. The motivation behind this is the local development build is relatively new to Core and, as things in Core tend to be used as a model or starting point for others, looking at allowing that environment to be flexible enough that someone can pick it up to use it generally if they don't have a preferred environment already or have specific requirements that make a generalized solution appropriate.

I think I understand the reasoning and I install Query Monitor on all my sites, thanks @johnbillion! I'm just not certain that something as opinionated as this belongs in core instead of a plugin.

A quick POC plugin. ​https://github.com/afragen/group-plugin-installer

[kraftbj]

I can appreciate that. There are two issues:

1. Adding the framework to be able to auto-install plugins based on environmental variables. I think there's no objection to having that in place so far in this ticket.

2. The perhaps questionable bit: Whether or not Core should auto-install any particular debugging plugin as part of the local development package out of the box.

I'm okay and would push to be just a little opinionated in terms of Query Monitor. In a perfect world, I'd love if Debug Bar was the quintessential debug plugin (as it is developed by the "WordPress.org Team"), but it isn't. In virtually all circles, Query Monitor _is_ that plugin. There are definitely other debug plugins to install also (to the point of the comment in #42879), but no matter what you're doing in WP, Query Monitor covers things relevant. I think being opinionated to the point of strongly encouraging developers (for Core or plugins/themes as they begin to use this local dev environment) to keep tabs on what QM outputs is an overall good thing——plenty of plugins are submitted to the repo with obvious issues, like PHP warnings, that were missed before submission.

That said, if the concept of environmental variable leading to plugin install is only blocked by whether or not Query Monitor should be installed, I'm perfectly fine with a compromise of infrastructure only. It can always be added later if the demand/need is present.

[afragen]

@kraftbj, you have distilled this down to its two core points perfectly.

I don’t have any objections. I was simply pointing out a way for a more opinionated installation of a group of plugins. In the WP Debugging plugin I give the user an in your face choice to install Query Monitor or Debug Bar.