Plugin dependencies: Allow a mu-plugin to fulfil a dependency

[johnbillion]

See discussion on #60504 for background.

An inactive plugin that has a dependency that is fulfilled by a mu-plugin is prevented from being activated as its dependency is considered unfulfilled. It should be possible for a mu-plugin to fulfil a plugin dependency.

It may be that a new filter or a default mu-plugin loader needs to be introduced so facilitate this.

[costdev]

​The PR on #60504 enables the existing wp_plugin_dependencies_slug filter to be used to replace Must-Use plugins with their loader file.

---

However, before we consider changing Core to facilitate Must-Use plugins as dependencies, I think it would be beneficial to explore the concept of standardizing Must-Use plugin loading.

The benefits for Core and Must-Use plugin users by introducing an easy-to-adopt approach to this manual process appear much wider than the Plugin Dependencies feature. Additionally, if we made changes to Core to facilitate Must-Use plugins as dependencies, then later introduced a standardized Must-Use plugin loading layer, then we'd have to maintain both.

There are many implementations of Must-Use plugin loaders out there, which is part of the problem in itself. I think we could produce a better result if we hold off on coding for now, and begin by exploring the behaviours of Must-Use plugin loaders. Essentially a list of Need -> Internal configuration layer -> Expected outcome(s).

We may even find that rather than a default loader template, this instead takes the form of a Must-Use plugin API within Core that Must-Use plugin users utilize in their respective loaders.

Call for opinions: Should we focus on standardizing Must-Use plugin loading (via API or default template), and if so, start looking at the most basic needs and structure to introduce an early version that's easily iterated on?

[knutsp]

Let a mu-plugin stay as any .php file that exists in the mu-plugins folder, as now. Some recommedations is ok, like Plugin Name, Version headers and so on. The rest is up to the developer and/or any with file system access.

Make it simple. Create a register_dependency_plugin_slug function (or any better name) to add a plugin slug to a global array, or a class static, or a singleton object, array property, like the best of existing register_something functions. Maybe make this array immutable after all mu-plugins are loaded. In this way any, plugin author can add this, in prepartion to support being a loaded as a mu-plugin. Loader files, that load many individual plugins in subfolders, who does not register, allow multiple calls, one slug string at per call.

This allows any properly coded plugin, with no hard coded assumptions on where in the file systems it is loaded from, to work as a mu-plugin and also act as a dependency for other plugins.

A new plugin file header may be added, to indicate mu-plugin support, like network, but this is not essential

A mu-plugin declaring own dependencies should continue to be ignored, as developer territory.

[oglekler]

This ticket was discussed during bug scrub.

This can be accomplished without a change in core, only a change in the my-plugin.

It needs further discussion and possibly some documentation instead of a patch.

Add props to @afragen

[afragen]

Adding link to an MU Loader plugin that accepts an array of plugins to add as mu-plugins and achieves all the other desired results.

​https://gist.github.com/afragen/9117fd930d9be16be8a5f450b809dfa8