Multidomain Bundle Laravel Package

Technical Evaluation

Architecture fit. The first thing a TPM has to flag is a framing mismatch: kunstmaan/multidomain-bundle is a Symfony bundle, not a Laravel package. It is not a standalone library with a clean seam — it is an extension module for KunstmaanCMS, and its real dependencies are the CMS's own bundles (kunstmaan/node-bundle, admin-bundle, pagepart-bundle). Its unit of value is the CMS node tree: the bundle adds a host-resolution layer in front of node lookups and scopes admin editing by a configured domain. So the architectural question is not "does this drop into our app," it is "are we committing to KunstmaanCMS as the content platform." If the answer is no, this package is out of scope regardless of its quality.

Integration feasibility. Feasible in exactly one scenario: an existing or greenfield KunstmaanCMS install on Symfony with Doctrine ORM. There, adoption is roughly composer require, a host-config map (host → domain/locale/settings), a Doctrine schema update for the domain entity, and admin permissions per domain. Anywhere else — Laravel, a bespoke Symfony app, a headless stack — feasibility collapses to "import a full CMS plus an unmaintained bundle," which is a platform decision with a multi-quarter blast radius, not a package decision.

Technical risk. High. Zero stars, zero dependents, and no visible release cadence place this in effectively-unmaintained territory; the broader Kunstmaan CMS family has been dormant for years, which means no upstream security response and a hard ceiling on Symfony/PHP versions. The low dependent count is partly an artifact of distribution — the bundle historically shipped inside the kunstmaan/bundles meta-package, so install counts don't surface here — but that nuance does not change the maintenance conclusion. Secondary risks: tight coupling to node-bundle internals (upgrades are all-or-nothing), Doctrine schema/entity coupling that makes rollback awkward, and genuinely subtle multi-tenant correctness issues around host detection behind proxies/CDNs and cache key scoping.

Key questions.

• Is the upstream repository archived, and who is the named owner of security patches in our org?
• What are the actual Composer constraints — PHP version, Symfony major, Doctrine major — and does a clean composer install resolve on our target runtime today?
• How many sites, and is content shared across domains or siloed? (This drives most of the design.)
• What is the locale/hreflang/canonical strategy, and who owns SEO correctness across domains?
• Are we behind a CDN or reverse proxy, and which header is authoritative for host?
• Do we already have an internal Kunstmaan fork, or would we be starting one?
• Is the realistic alternative a tenancy layer on our current framework rather than a CMS migration?

Integration Approach

Stack fit. Laravel: no — the cost is a framework migration dressed up as a package evaluation. Symfony without Kunstmaan: no, unless the CMS is already on the roadmap. Symfony + KunstmaanCMS: yes, and the bundle is close to mandatory, because managing multiple sites from one install is otherwise hand-rolled host logic around the node tree. That last case is the only one where I would spend evaluation time.

Migration path. Three viable shapes. (a) Greenfield Kunstmaan + bundle — cleanest, but you are buying the CMS, and the bundle's maintenance posture becomes your problem. (b) Existing Kunstmaan, pin and isolate — lock the bundle and CMS to a known-good Composer set, then treat upgrades as projects, not chores. (c) Fork and own — vendor the bundle into our namespace, add CI and a smoke test matrix, and accept stewardship. I would explicitly reject "port this bundle to Laravel"; the domain concepts (host config, node-scoped domains) are cheap to reimplement as a tenant table plus host-based routing, and the port would carry the CMS's coupling without the CMS.

Compatibility. Pin everything and verify by resolution, not by reading docs. Concretely: confirm the PHP upper bound against our runtime (PHP 8.1+ deprecation noise is likely on a dormant Symfony bundle), confirm the Symfony major matches, confirm the Doctrine ORM/DBAL majors match, and confirm the kunstmaan/bundles meta-package version that pulls this in. Run the resolve in a throwaway container so a failed install is a one-hour finding rather than a two-week surprise.

Sequencing. (1) Decision gate: confirm the CMS commitment before any code. (2) Compatibility spike: Composer resolve + boot a minimal app + one request through host resolution. (3) Fork, CI, baseline smoke tests. (4) Doctrine schema and host-config map for the first two domains. (5) Admin roles and per-domain editorial permissions. (6) Staging with real DNS and real Host headers, including apex vs www and proxy behavior. (7) SEO and canonical/hreflang validation. (8) Per-domain cutover behind a flag, one site at a time.

Operational Impact

Maintenance. Assume self-maintenance. Budget a named owner, a fork in our VCS, and a standing quarterly task to check for Symfony/PHP EOL drift. The realistic effort is small in steady state and spiky at upgrade time, because the bundle sits on node-bundle internals — there is no safe incremental upgrade path. Security patching is entirely ours; there is no upstream to wait for.

Support. No vendor, no SLA. Community support is StackOverflow and archived project channels with low activity; the practical escalation path is the engineer who forked it. Document that in the runbook before launch, not after.

Scaling. The bundle is not the scaling bottleneck — the CMS is. It does, however, impose two scaling constraints worth designing around early: cache keys must include the resolved host, or content leaks between domains; and admin performance degrades as node count multiplies across domains, so editorial list views need attention at roughly the point you exceed a handful of sites. CDN and Varnish config must be per-host, and TLS/SNI terminates before the bundle ever sees the request.

Failure modes. The ones that actually page someone: an unconfigured or mis-cased host falling through to a default domain and silently serving the wrong site; cache poisoning across domains from unscoped keys; www/apex or trailing-dot mismatches in host comparison; a schema migration that orphans nodes from their domain; editorial users editing another domain's content due to loose permissions; and SEO bleed — shared sitemaps, robots, or canonicals pointing at the wrong host, which is invisible until rankings move. Also expect a proxy header rewrite to break host resolution in production but not staging.

Ramp-up. Meaningful. Engineers need Symfony fundamentals plus Kunstmaan's node/pagepart/domain model — the domain concept in particular is non-obvious and lives in node-bundle, not here. Editors need domain-scoped admin training, since the failure mode of a confused editor is published content on the wrong site. Plan two to three weeks of ramp for one engineer and a short editor onboarding session; that cost is the CMS's, not the bundle's, but it lands on this initiative's budget.

Recommendation. Treat this as a CMS platform decision with a bundle attached, not a package adoption. Proceed only if KunstmaanCMS is already committed or strategically required; in that case fork, pin, and staff an owner. If the current stack is Laravel or a non-Kunstmaan Symfony app, decline and scope host-based tenancy natively — the bundle's 0/0/0 signal, dormant upstream, and framework mismatch make it a maintenance liability rather than an accelerator.