Forced Install of `wp-content/mu-plugins/wpstarter-mu-loader.php` Conflicts with Existing MU Plugin Loaders

[timnolte]

Describe the bug

There needs to be a way to disable the forced us of the wp-content/mu-plugins/wpstarter-mu-loader.php MU Plugin loader especially when there are existing MU Plugins that are installed via Composer and use other MU Plugin loaders.

To Reproduce

Steps to reproduce the behavior:

1. Install the https://packagist.org/packages/ndigitals/wp-local-media-proxy MU Plugin via Composer.
2. This includes/requires the https://packagist.org/packages/boxuk/wp-muplugin-loader MU Plugin Loader package.
3. Both loaders will attempt to load MU Plugins.

Expected behavior

Provide a config option that prevents the installation of this loader.

Additional context

This didn't existing in early beta releases.

[timnolte]

As an update, what I've relegated to doing, for now, is to add a post-install-cmd & post-update-cmd script to remove that file.

        "remove-muplugins-loader": [
            "rm public/wp-content/mu-plugins/wpstarter-mu-loader.php"
        ],

[timnolte]

Unfortunately, I come to find pretty quickly that trying to simply rm the file in the way I proposed is not viable. For starters it is likely not cross-platform compatible. The bigger issue is that if you run a composer install --no-dev and then follow that by a composer install, or even just multiple composer install executions, you'll get failures since the file is deleted the first time and then it's not there later. Attempts to get around errors if the file is no longer there go back to the first issue of things not being cross-platform compatible. I'm going to take the route of adding this file to the prevent-overwrite list and just add an fake version of this file and commit it to the repository.

[gmazzap]

Thanks @timnolte

I think that managing that kind of loaders is a matter of the website-level handling, like WP Starter or Bedrock, and a plugin should not do that, because it has no knowledge of the wider website architecture. For example, that would make such a plugin incompatible with a platform like wp.com VIP.

Anyway, WP Starter is very flexible and pretty much every aspect of it are configurable, so it make sense to add this to the list.

---

FYI one way to handle this would be to have a custom template for the loader that would just be an empty file.

To use custom templates, you need to define a custom template folder via the templates-dir configuration and place in that folder a file named like the current template. You don't need to place in the custom folder all the templates: files not found in the custom folder fallback to the default WP Starter templates folder. You can even have a separate Composer package with your custom WP Starter templates, and then define the custom template directory inside the vendor folder.

[gmazzap]

@timnolte I just realized that the MU loader is created in one step called build-mu-loader, see https://wecodemore.github.io/wpstarter/05-WP-Starter-Steps.html#muloaderstep

WP Starter allows you to disable specific steps, see docs: https://wecodemore.github.io/wpstarter/05-WP-Starter-Steps.html#skipping-steps

So you can have a configuration like:

{
    "skip-steps": [
        "build-mu-loader"
    ]
}

And that will achieve exactly what you're asking.

I'm closing this issue, please reopen if something is not working for you.

[timnolte]

@gmazzap thanks for that detail. We were resorting to creating an empty version of that file and directing WP Starter to not overwrite it. I'd much rather use the skip-steps setup.