Env: MU Plugin support

[mikelking]

Feature request: In order to thoroughly test some plugins and theme one would need to be able to access a mu-plugin directory. This directory should be relative '../mu-plugins' to the current startup directory.

Potential solution: The easiest way to add this would be a config option to override the default mu-plugins OFF behavior. see example below.

{
    "core": "WordPress/WordPress#5.2.0",
    "plugins": [ "WordPress/wp-lazy-loading", "WordPress/classic-editor" ],
    "themes": [ "WordPress/theme-experiments" ],
    "mu-plugins": "true"
}

Alternative implementation: An alternative would be to explicitly define the mu-plugin path:

{
    "core": "WordPress/WordPress#5.2.0",
    "plugins": [ "WordPress/wp-lazy-loading", "WordPress/classic-editor" ],
    "themes": [ "WordPress/theme-experiments" ],
    "mu-plugins": "../mu-plugins"
}

The later could be used to define the mu-plugin path constant WPMU_PLUGIN_DIR see => https://wordpress.org/support/article/must-use-plugins/

[noahtallen]

Would we want to make this similar to the other sources by using something like "mu-plugins": [ "../path/to/a/muplugin", "path/to/another/muplugin" ]

This reminds me that it would be useful to support entire directories of plugins and themes. Sometimes, a repository might contain several themes in the top level, so it would be useful to detect that and then install all of them on the site. This could also be used for directories containing several mu-plugins or plugins.

cc @noisysocks

[noisysocks]

Would we want to make this similar to the other sources by using something like "mu-plugins": [ "../path/to/a/muplugin", "path/to/another/muplugin" ]

Yes I think this is the way to go!

[mikelking]

This is kind of what i was trying to document in the alternative suggestion above, but probably failed to :(

However keep in mind that WordPress looks at the mu-plugins path and autoloads ALL php files in that path so specifying individual mu-plugins would not be the way WordPress handles this construct.

I am happy to support with prerelease testing & QA once I figure out how to... of course ;)

Just ping me when there's something to work with.

[noahtallen]

keep in mind that WordPress looks at the mu-plugins path and autoloads ALL php files in that path

That's a fair point. Say I have a plugin 'foo', and I add this configuration to support it: "mu-plugins": [ "../path/to/foo" ]. Then, it would be mounted to the Docker filesystem at wp-content/mu-plugins/foo. But the problem is that a loader .php file doesn't exist, so it would actually need to be: "mu-plugins": [ "../path/to/foo", "../path/to/foo-loader.php" ]. (assuming foo-loader.php requires the other directory).

That's a bit clunky and inflexible. How do folks typically handle this issue?

[noisysocks]

keep in mind that WordPress looks at the mu-plugins path and autoloads ALL php files in that path

WordPress does this for plugins too, no? For example, Hello Dolly is a single file. Would it work if we ensured that both files and directories can be mapped?

{
    "plugins": [ "/path/to/a/plugin/directory", "/path/to/a/plugin.php" ],
    "mu-plugins": [ "/path/to/a/mu/plugin/directory", "/path/to/a/mu/plugin.php" ]
}

[noisysocks]

Been thinking my preferred approach to this would be to add "mu-plugins" and expand the "plugins", "themes" and "mu-plugins" config to accept either a single directory or multiple files and/or directories.

So, this is valid:

{
    "plugins": [ "~/plugins/acf", "~/plugins/gutenberg", "~/plugins/hello-dolly.php" ],
    "mu-plugins": [ "~/mu-plugins/one.php", "~/mu-plugins/two.php" ]
}

And so is this:

{
    "plugins": "~/plugins",
    "mu-plugins": "~/mu-plugins"
}

In doing this we can also remove the temporary workaround (search for TODO) in build-docker-compose-config.js and update Gutenberg's .wp.env.json to be:

{
    "core": "WordPress/WordPress",
    "plugins": [ ".", "./packages/e2e-tests/plugins" ],
    "mu-plugins": "./packages/e2e-tests/mu-plugins"
}

[noahtallen]

to accept either a single directory or multiple files and/or directories.

Nice! This solves some other issues for me too. I've wanted a way to mount a directory containing a bunch of themes instead of specifying them one by one and this would solve that. I'll make a PR for this :)

[noahtallen]

I have an approach up in: https://github.com/WordPress/gutenberg/pull/21229. I think it works pretty well; I'm also open to suggestions for improving code readability

[whyisjake]

Kinda related issue here: https://github.com/WordPress/gutenberg/issues/21595

[noahtallen]

resolved by #22256 which allows you to map any local directory to any location in the WordPress install (i.e. you can set the mu-plugins directory now.)

so:

# .wp-env.json
{
  "mappings": {
    "wp-content/mu-plugins": "path/to/mu-plugins"
  }
}