Multisite Bundle Laravel Package

Technical Evaluation

Architecture fit. valiton/multisite-bundle is a Symfony bundle, not a Laravel package. It hooks into the Symfony full-stack framework through a DI extension, a kernel event subscriber, and the Symfony CMF RoutingBundle chain router, and it typically persists site definitions via Doctrine PHPCR-ODM. Laravel exposes none of those seams: there is no bundle registration, no ChainRouter, no HttpKernel event lifecycle, and no PHPCR document manager by default. The package therefore cannot be dropped into a Laravel application — it can only be mined for design patterns.

Integration feasibility. Low as a dependency, moderate as a reference. Composer resolution is the first blocker: the bundle's Symfony and CMF version constraints predate Symfony 4, and the PHPCR-ODM/Jackalope transitive tree is heavy and itself largely dormant. Even on a Symfony application we would be adopting an end-of-life stack.

Technical risk. High on every axis:

• Abandonment. 5 stars, 0 dependents, no meaningful downstream usage. Effectively no upstream maintenance, no security patch path, no issue triage.
• Dependency depth. Pulling it in pulls Symfony CMF RoutingBundle, Doctrine PHPCR, PHPCR-ODM, and a JCR/PHPCR backend — a parallel persistence stack alongside Eloquent.
• Conceptual mismatch. Its site resolution is host-based routing layered over a CMF content tree. Most Laravel multisite requirements are Eloquent-model tenancy with host or path prefix resolution, which Laravel handles natively.

Key questions for the product/engineering conversation.

1. Is multisite a committed roadmap item or a speculative "maybe"? If speculative, this evaluation should stop here.
2. What is the tenancy model — separate database per site, shared schema with site_id scoping, or shared data with per-site presentation only?
3. Is site resolution host-based (acme.com vs beta.com), path-based (/uk, /de), or both?
4. Do sites need independent content models, or one schema with site-scoped rows?
5. Who administers sites — engineers via config, or business users via an admin UI?
6. Are we willing to own a fork of an unmaintained dependency indefinitely?

Integration Approach

Stack fit. Treat the bundle as an architectural reference, not a dependency. The transferable ideas are: a SiteProvider/SiteRepository abstraction, host-to-site matching at request entry, and a site context object made available to routing, views, and caching. All three map cleanly onto Laravel middleware, a Site model, and container-scoped context.

Migration path. Do not install the bundle. Reimplement the concepts natively. A credible Laravel implementation is small: a Site Eloquent model (host, locale, theme, status), a ResolveSite middleware that matches Request::getHost() against a cached site map and binds a SiteContext singleton, host-constrained route groups or a route resolver, and a global scope or query builder macro for site_id. This is on the order of a few days to two weeks depending on admin UI scope, versus weeks of fighting PHPCR integration for a worse result.

Compatibility. Assume incompatible. Symfony 2.x/3.x-era constraints will not resolve against a modern Laravel/Symfony dependency graph, and forcing it via --ignore-platform-reqs produces a runtime that fails at container compile time. There is no Laravel service provider, no publishable config, no facade — nothing to bridge.

Sequencing.

1. Lock the tenancy decision (database-per-site vs shared schema) — everything downstream depends on it.
2. Spike a build-vs-buy comparison: stancl/tenancy, spatie/laravel-multitenancy, or a custom ~200-line implementation. For host-based, shared-schema multisite, custom is usually cheapest.
3. Implement site resolution middleware and a cached host→site map with an explicit fallback behaviour.
4. Make routing, cache keys, queues, and storage paths site-aware.
5. Build or buy the site admin surface.
6. Only then touch content migration.

Recommendation. Reject as a dependency; adopt as a design reference. The 0.025 score is consistent with what the repository inspection shows.

Operational Impact

Maintenance. Zero upstream. Any defect, PHP version bump, or security advisory in the transitive tree becomes our problem. If we forked, we would own a PHPCR-coupled codebase our team does not know — the worst of both worlds.

Support. No documentation beyond Symfony CMF-era material, no maintainer response, no community. Internal onboarding would rely on reading source. Contrast with stancl/tenancy or spatie/laravel-multitenancy, which have active maintainers, docs, and issue histories.

Scaling. The bundle's model implies a PHPCR/JCR backend — an additional stateful service to operate, back up, and monitor, sitting beside our existing database. A native Laravel approach scales with infrastructure we already run: the site map is cacheable in Redis, and per-site cache namespacing is a solved problem. The realistic scaling cost of the native path is cache-key discipline, not infrastructure.

Failure modes to design against (native path).

• Host header spoofing — resolution must validate against an allowlist, never trust Host blindly; otherwise cross-site data exposure.
• No site match — decide explicitly between 404 and a configured default; silent fallback to the wrong site is the dangerous option.
• Context-free execution — queue workers, scheduled commands, and console invocations have no request host, so the site context must be explicitly bound and propagated through jobs, or jobs will silently operate on the default site.
• Cache bleed — any cache key (response, view, query, config) not namespaced by site becomes a cross-tenant leak. This is the single most common production incident in multisite Laravel builds.
• Migration fan-out — schema changes must run across all site databases or be safely idempotent for shared-schema.
• Config and credential leakage — per-site third-party credentials must be scoped and encrypted, not global.

Ramp-up. Adopting the bundle means ramp-up on Symfony DI, CMF routing, and PHPCR simultaneously — an unreasonably steep curve for the delivered value. A native Laravel implementation is legible to any mid-level Laravel engineer within a sprint, and the resulting code is one the team can actually maintain.