Bedrock Autoloader Laravel Package

Product Decisions This Supports

• Site architecture standardization: Confirms whether Bedrock/Composer-managed WordPress is a supported hosting pattern for your product or agency delivery model — the autoloader is a foundational piece of the Bedrock developer experience.
• Build vs. buy for plugin management: If you're shipping a WordPress product that needs deterministic plugin activation (e.g., managed hosting, white-label distributions, client maintainer handoff), this package answers "should we build our own mu-plugin loader?" with a credible no.
• Roadmap signaling for multi-tenant / platform-tier offerings: Versioned mu-plugin autoloading with a stable, namespaced API (Roots\Bedrock\Autoloader\Autoloader) is exactly the kind of primitive a platform team wants to depend on when offering a curated plugin catalog to customers.
• Upgrade planning and PHP version policy: The PHP 8.2+ requirement is a direct input to your minimum-supported-runtime roadmap and to any support SLAs you publish for WordPress products.
• Dependency isolation and testability: The side-effect-free constructor + injected mu-plugin path makes the autoloader unit-testable — relevant if you have engineering standards around testable integration points in your WordPress product stack.
• Use cases: agency Boilerplate/Bedrock sites, managed WordPress hosting, plugin distribution for large multi-site installs, and CI-verified plugin activation flows.

When to Consider This Package

Adopt when:

• You run WordPress on Bedrock (or another Composer-based, mu-plugin-centric layout) and want standard plugins treated with mu-plugin loading guarantees (no deactivation from wp-admin, guaranteed load order).
• You control the deployed plugin set and want activation to be a deploy-time concern rather than a dashboard action — common in agencies, managed hosts, and platform products.
• You need a namespaced, testable loader with a documented constructor API rather than a legacy global scope snippet.
• You can commit to PHP 8.2+ on the target fleet (the v2.0.0-beta.1 hard requirement).
• You want the e2e-backed behavior introduced in this release (mu-plugin global variable scope fix, side-effect-free construction) so autoloading is verifiable and won't silently break plugin bootstrapping.

Look elsewhere when:

• You are on shared hosting or a vanilla WordPress install where mu-plugins and Composer are not part of the deployment model.
• You cannot yet move to PHP 8.2+ — the v1.x line remains your path until the fleet upgrades.
• You are pinned to pre-2.0 namespace (Bedrock\Autoloader or legacy namespace) and the migration cost outweighs the new API's testability gains.
• You require stable, non-beta dependencies for production; v2.0.0-beta.1 is a beta, and the namespace change is a hard breaking change for any in-house code referencing the old class.
• You need richer plugin governance (per-site enablement, feature flags) — this is a loader, not a plugin management platform.

How to Pitch It (Stakeholders)

Executive summary: This is the Roots team's official v2.0.0-beta.1 of bedrock-autoloader, the component that lets Composer-managed WordPress sites (Bedrock) treat standard plugins as guaranteed-load mu-plugins. The release modernizes the codebase — PHP 8.2+ requirement, a clean Roots\Bedrock\Autoloader namespace, side-effect-free construction with an injected mu-plugin path, a fix for global variable scoping in autoloaded mu-plugins, and new end-to-end tests — which materially improves testability and reliability. It is a breaking release: the namespace and constructor signature change, so any in-house code touching the autoloader must be updated, and PHP 8.2 becomes a hard floor.

Engineering summary: v2.0.0-beta.1 makes the Autoloader instantiable without side effects (new Autoloader($muPluginDir)), moves boot into an explicit boot() / markLoaded() flow, and ships the canonical mu-plugins/bedrock-autoloader.php shim that guards on is_blog_installed() and class_exists. The scope fix (#44) and e2e tests (#45) close a real correctness gap for autoloaded plugins that rely on globals. Adopt only on Bedrock deployments on PHP 8.2+; plan the namespace migration as part of the upgrade, and treat the beta as a pre-GA signal rather than a drop-in for conservative production fleets.

Decision framing for PMs: Treat this as a go/no-go input on Bedrock as a supported platform tier and on your PHP 8.2 minimum. It is a build-vs-buy "buy" on a well-scoped primitive that would otherwise be bespoke agency glue code. The beta status means the decision today is "start migration planning and pilot on non-critical sites," not "flip the switch on the flagship product."