Multisite Bundle Laravel Package

Product Decisions This Supports

• Multi-brand / multi-domain architecture. The core decision this package touches: one codebase and one content tree serving N sites, versus separate stacks per brand, region, or microsite. The bundle's premise — resolve the site from the request host, give each site its own content root, fall back through a per-site template chain — is the "one deploy, many sites" model. Use it to force the tradeoff into the open: shared release train and shared editorial tooling, at the cost of shared blast radius.
• Content reuse vs. duplication. Per-site roots and template overrides imply a specific answer to "is content inherited across sites or copied per site?" That's a product decision with real editorial cost, and this package only makes sense if you've decided on inheritance with overrides.
• Localization and regionalization strategy. Locale-per-site versus shared content with regional variants. Committing to this model means "add Germany" is a site record plus content plus templates, not a new application — which makes market expansion a plannable line item rather than a re-platform.
• Roadmap sequencing for domain launches. Because adding a site is roughly config + content root + template set, you can price "site #4" credibly in a roadmap instead of estimating a rebuild.
• Adopt vs. build. The package is a thin layer — a site entity, a host resolver, a request listener, a template fallback chain. Even if you reject it, it works as a reference spec for a one-to-two sprint in-house implementation you fully own.
• Design-system governance. Template fallback per site naturally produces a shared base theme with per-site overrides. That's an organizational decision about who owns the base theme and how overrides are reviewed, not just a technical one.
• Editorial permissions and publishing scope. A shared content tree across sites makes "who can publish where" an explicit product requirement you must spec up front, not something you can defer.

When to Consider This Package

Adoption criteria — treat these as conjunctive:

• You are already committed to Symfony CMF / PHPCR. The bundle is not meaningful outside that stack. If you're not on CMF today, do not let this package be the reason to adopt it; CMF itself is a bigger risk than this bundle.
• Site count is small and stable — roughly 2–10 — with substantial content overlap between them.
• Host or subdomain selection is sufficient. You do not need per-site data isolation, per-site databases, or independent deploy cadence.
• You can fork, vendor, and own it. Five stars and zero dependents means no downstream testing, no community bug-finding, and no one else to inherit the maintenance. Budget an owner.
• The use is low-blast-radius — internal, or a defined stopgap during a migration with a written exit.

Look elsewhere when:

• Greenfield, or you need current PHP / Symfony. Version constraints on a package this old are typically the first hard blocker; assume a compatibility audit before any commitment.
• Security, accessibility, or compliance review applies. An unmaintained dependency with no dependents is a supply-chain finding, not merely technical debt.
• You need headless or multichannel APIs, editorial workflow, or per-site publishing pipelines. Mature multi-site products (Sulu, Ibexa, Sylius for commerce; Drupal, Wagtail, or Craft if you can leave the Symfony ecosystem) operate at a level this bundle doesn't reach.
• Sites have divergent lifecycles or you need tenancy-grade isolation guarantees.

How to Pitch It (Stakeholders)

For executives: this is not a platform bet. It's a small, unmaintained MIT-licensed bundle (5 stars, zero dependents) that does one narrow job — deciding which "site" an incoming request belongs to and letting content and templates differ per host — inside Symfony's Content Management Framework. The durable value is the pattern, not the code. Pitch it as a one-to-two week spike to validate the "one platform, many sites" model, with an explicit budget line for replacement or in-house build, and a named maintenance owner. Do not attach a multi-brand roadmap to it without that owner.

For engineering: the reusable parts are the site entity, the host-based site selector, and the template fallback chain; treat the repository as a spec and a starting point. Before adopting, audit composer constraints against your PHP and Symfony versions, check for abandoned transitive dependencies, and decide between fork-and-vendor and reimplementing the few hundred lines the pattern actually needs. My recommendation: spike it, don't depend on it. Use it to settle the architecture question quickly, then own the code.