What is the best way to load my mu-plugins?

[StevenDufresne]

Describe the problem

Context: https://wordpress.slack.com/archives/C04EWKGDJ0K/p1710907229360679

wp-now currently mounts its own mu-plugins folder from ~/.wp-now based mu-plugins (ref). This isn't ideal because many websites include mu-plugins.

Leading questions

• Why does wp-now need to use mu-plugins?
  • Why not drop-ins?
  • Why not create a plugin that includes all the modifications?

... I have some ideas for fixes but I'm curious about those answers first.

[bgrgicak]

I think that we should allow both to work together. WP-now should be able to add mu-plugins alongside project mu-plugins.

[adamziel]

AFAIR, the original reason why @danielbachhuber and @sejas went for mounting was to avoid modifying the files inside the directory where the developer ran wp-now as it is unexpected and would show up in git status.

That being said, specific mu-plugin PHP can be mounted inside mu-plugins without mounting the entire directory.

Why does wp-now need to use mu-plugins?

One mu-plugin that is typically required is the sqlite-database-integration plugin.

Why not drop-ins?

It uses the db.php drop-in plugin, but the SQLite integration is more complex than that and ships multiple PHP files. We could potentially build them into a single db.php file and ship that, though.

Why not create a plugin that includes all the modifications?

Do you mean a regular WordPress plugin? We originally did that, but it's problematic. If the SQLite plugin ever gets disabled, the site is unusable. If the update fails, the site is unusable. If you want to enable a multisite and disable the SQLite plugin, the site is unusable. That's why it's an mu-plugin now.

[sejas]

I agree that a user should be able to add their mu-plugins. wp-now should support it for most if not all the WordPress modes (plugin, theme, wordpress, playground).

Our initial idea was to hide complexity for the final user, and share the same basic configuration across all the sites.

A single file would make it easier for developers to include in .gitignore and other tools.

Changing the logic to avoid mounting and writing the file (or files) directly to the project directory seems like a good approach. And that file can be overwritten after each start so wp-now can keep updating its functionality.

[StevenDufresne]

Would it make sense to add a file to load user mu-plugins?

~/.wp-now/mu-plugins/0-load-user-plugins.php

foreach ( scandir( "~/path-to-user-folder/wp-content/mu-plugins" ) as $file ) {
	// require user file
}

[bgrgicak]

Would it make sense to add a file to load user mu-plugins?

This seems like a simple solution that would unblock the usage of mu-plugins.

Alternatively, we could mount files from Playground mu-plugins to user mu-plugins and then mount the entire user folder.

[sejas]

Would it make sense to add a file to load user mu-plugins?

~/.wp-now/mu-plugins/0-load-user-plugins.php

foreach ( scandir( "~/path-to-user-folder/wp-content/mu-plugins" ) as $file ) {
	// require user file
}

I think it's a smart solution. The path lives in the VFS so we would need to mount the ~/path-to-user-folder/wp-content/mu-plugins to another place, like wp-content/users-mu-plugin.

Alternatively, we could mount files from Playground mu-plugins to user mu-plugins and then mount the entire user folder.

I think I prefer this solution as it's simpler. We could load the users's mu-plugins directly and add a single mu-plugins/wp-now.php file inside that directory.

[adamziel]

Surfacing what @tellyworth said:

The snippet of code above? Something like it might work if it was done by wp-now, I’m not sure we can use it on our side though because it would require patching wp-now. We’d like to use wp-now as a default dev/test environment for our repos, so anyone could essentially just clone a repo and run npm i && wp-now without having to install Docker etc. A PR for wp-now implementing something like Steve’s method might do as a workaround, but I think there would be general edge cases where it fails because some plugins make assumptions about WPMU_PLUGIN_DIR (ie include WPMU_PLUGIN_DIR . '/my-folder/my-file.php would fail because WPMU_PLUGIN_DIR points to wp-now’s internal single-file folder).

[flexseth]

Would it be possible to use the new Requires Plugins header and custom plugin(s) to bootstrap the features you're requesting?

Wouldn't be Playground specific - but a possible workaround?

I haven't ever worked with mu-plugins and am having a bit of trouble distinguishing between a Must Use plugin and including the Requires Plugins header...

Distinction?

Is the difference that a mu-plugin is required for the site to function, whereas a Requires Plugins header is made to make a particular feature work?

[adamziel]

@flexseth mu-plugins are a developer feature, you'd never install one from the WordPress plugin directory. They don't require any headers, too.