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.

[callumbw95]

Hi everyone,

Adding a thought to this, even though as the underlying goal remains very relevant for modern development workflows, and would be very useful in helping invite more people into the community of contributors.

A powerful and common pattern for solving this today is to fork the official WordPress Docker image and create a custom development environment. One can create a Dockerfile that uses the official image as a base and then executes WP-CLI commands during the image build process to install and activate a standard suite of testing or development plugins.

For example, a developer's Dockerfile could include:

Dockerfile

FROM wordpress:latest

# Switch to root to install dependencies if needed, then switch back
# For the official WP image, WP-CLI commands should be run as the www-data user.
# Install and activate a suite of useful development plugins
RUN su www-data -c "wp plugin install query-monitor user-switching debug-bar --activate"

# You could add other development tools or configurations here
# For example, copying a custom php.ini for debugging
# COPY --chown=www-data:www-data dev-php.ini /usr/local/etc/php/conf.d/

By running docker build with this file, a developer can create a custom image with Query Monitor, User Switching, and other tools pre-installed and ready to go. This approach is:

• Declarative: The Dockerfile itself serves as the version-controlled list of dependencies.

• Reproducible: Every developer on the team gets the exact same environment.

• Comprehensive: It goes beyond just plugins and can manage PHP extensions, server configurations, and other dependencies.

This container-based workflow effectively solves the problem described in the ticket and is a widely adopted best practice. It might be one of the reasons a dedicated Core feature for this has not gained more traction, but would love to hear any feedback about this solution.