hipdevteam/ion-mu-installer

Composer plugin that wires ION MU into wp-content/mu-plugins/load-mu-plugins.php on every install and update

v1.0.0 2026-07-28 14:23 UTC

Requires

• php: >=8.1
• composer-plugin-api: ^2.0

Requires (Dev)

• composer/composer: ^2.0

MIT

• ION

• wordpress
• composer-plugin
• mu-plugin
• ion-mu

Published on Packagist.org on 2026-07-28 08:38 UTC

README

Composer plugin that wires hipdevteam/ion-mu into wp-content/mu-plugins/load-mu-plugins.php on every install and update.

You do not require this package directly — ION MU depends on it.

Why it exists

WordPress only auto-loads top-level .php files in mu-plugins/, never subdirectories. Composer installs a package as exactly one directory, so composer require hipdevteam/ion-mu produces:

wp-content/mu-plugins/ion-mu/ion-mu-loader.php   ← one level too deep

and WordPress runs none of it. Something has to write a top-level file that reaches back into the package. That something cannot be ION MU itself, for two reasons:

1. A Composer package has exactly one type. ION MU must be wordpress-muplugin so composer/installers places it in mu-plugins/ rather than vendor/, which leaves no way for it to also be composer-plugin.
2. A package's own scripts never run when it is installed as a dependency. Only the root project's do. So ION MU cannot hook post-update-cmd on its own behalf.

Hence a separate package, which is what every installer in the WordPress Composer ecosystem ends up doing.

Setup

One entry in the site's composer.json:

{
    "config": {
        "allow-plugins": {
            "composer/installers": true,
            "hipdevteam/ion-mu-installer": true
        }
    }
}

Composer has required explicit approval for any package that executes code at install time since 2.2. There is no way to opt out, and no way for a package to approve itself — that is the point of the mechanism.

If the entry is missing, Composer prints a warning, skips this plugin and carries on. The install succeeds, the loader is never written, and ION MU never runs. The site looks healthy and reports nothing. Sites that cannot allow Composer plugins should call install-loader.php from post-update-cmd instead — see the ION MU README.

What it writes

if (is_file(__DIR__ . '/ion-mu/ion-mu-loader.php')) {
    require_once __DIR__ . '/ion-mu/ion-mu-loader.php';
}

The guard matters: load-mu-plugins.php outlives the package it points at. Deleting mu-plugins/ion-mu/ with an unguarded require_once is a fatal on every request, and mu-plugins have no Deactivate button and no recovery mode.

Re-running never duplicates the entry, and entries belonging to other packages are never rewritten. The install path comes from Composer's own InstallationManager rather than being assumed, so a site that relocates mu-plugins through extra.installer-paths — Bedrock, a renamed content directory — is handled without configuration.

Failures are reported through Composer's IO and never thrown: a plugin that throws aborts the whole install, and an unwritable mu-plugins/ is a deployment condition, not a reason to leave a site without its dependencies.

Licence

MIT — see LICENSE.