Weave Code
Multidomain Bundle Laravel Package
kunstmaan/multidomain-bundle
A Symfony bundle that adds multi-domain support to Kunstmaan CMS, letting a single installation serve several domains with their own hosts, locales, and content. Configure domains, route requests to the right site, and manage per-domain settings without duplicating your application.
[READ-ONLY] Subtree split of the Kunstmaan MultiDomainBundle -- master at Kunstmaan/KunstmaanBundlesCMS http://bundles.kunstmaan.be
Frequently asked questions about Multidomain Bundle
- Is kunstmaan/multidomain-bundle a Laravel package?
- No. It is a Symfony bundle built as an extension module for KunstmaanCMS, and it depends on the CMS's own bundles such as kunstmaan/node-bundle, admin-bundle and pagepart-bundle. There is no Laravel service provider, facade or config file, and no Laravel version is supported. Evaluating it as a Laravel Composer package is a framing mismatch, not a version-compatibility question.
- What does the Kunstmaan MultiDomainBundle actually do?
- It lets a single KunstmaanCMS installation serve several domains, each with its own host, locale, settings and content scope. The bundle adds a host-resolution layer in front of node lookups, so a request is mapped to the correct domain before the CMS resolves pages, and it scopes admin editing by configured domain. In practice it replaces hand-rolled host logic around the CMS node tree.
- Can I use this bundle in a Laravel application?
- No, not without importing the entire KunstmaanCMS platform onto Symfony, which is a framework and platform migration rather than a package install. Porting the bundle to Laravel is explicitly not worth doing: the underlying concepts are cheap to reimplement as a tenant table plus host-based routing on your existing framework. If you need multi-domain behaviour in Laravel, look at a tenancy or host-routing package instead.
- What are the Composer and platform requirements for kunstmaan/multidomain-bundle?
- The bundle requires Symfony with Doctrine ORM plus the Kunstmaan CMS bundles it extends, and the CMS family has been dormant for years, so PHP and Symfony major version ceilings apply. Pin every constraint and verify with a clean composer install on your target runtime rather than trusting the documented version ranges. Confirm the Doctrine major version too, since the bundle ships a domain entity and schema changes that are awkward to roll back.
- How do I install and configure multi-domain support in Kunstmaan CMS?
- Adoption is roughly composer require, a host-to-domain configuration map covering host, locale and per-domain settings, a Doctrine schema update for the domain entity, and admin permissions per domain. The configuration lives in the CMS's Symfony config rather than in a Laravel-style config file. Plan the domain map before writing content, because node scoping depends on it.
- Is kunstmaan/multidomain-bundle actively maintained and safe for production?
- Treat it as effectively unmaintained: the bundle shows no release cadence, zero dependents surfacing on the split repository, and the wider Kunstmaan CMS family has been dormant for years. That means no upstream security response and a hard ceiling on Symfony and PHP upgrades. The low dependent count is partly an artefact of it shipping inside the kunstmaan/bundles meta-package, but that nuance does not change the maintenance conclusion. If you adopt it, assign an internal owner for security patches.
- How does the bundle detect the correct domain when the site is behind a CDN or reverse proxy?
- Host detection depends on the request host being authoritative, so trusted proxy configuration and the forwarded-host header matter enormously. Get this wrong and visitors see the wrong site's content, or caches leak one domain's pages into another's cache keys. Test explicitly with the same headers your CDN sends in production, and include cache key scoping in your review.
- How do I handle hreflang, canonical URLs and SEO across multiple domains?
- The bundle stores a locale per domain, which feeds your canonical and hreflang output, but it does not own SEO correctness for you. You must decide whether content is shared across domains or siloed, then build canonical and hreflang rules on top of the per-domain settings. Assign a named owner for cross-domain SEO, because mistakes here are expensive to unwind after indexing.
- How can I test multi-domain routing locally and in staging?
- Use local host aliases or a hosts file entry per domain, and drive functional tests that send distinct Host headers so the resolution layer is actually exercised. If you fork the bundle, add a smoke-test matrix covering each configured domain plus a proxy-header case. Rollback is awkward because of the Doctrine entity and schema coupling, so rehearse migrations in staging first.
- What are the alternatives to kunstmaan/multidomain-bundle, and should I fork it?
- Outside KunstmaanCMS, the realistic alternative is a tenancy layer with host-based routing on your current framework rather than a CMS migration; Symfony without Kunstmaan does not justify it either. Inside an existing KunstmaanCMS install, three paths work: greenfield Kunstmaan plus the bundle, pinning and isolating a known-good Composer set with upgrades treated as projects, or vendoring the bundle into your namespace with CI and accepting stewardship. All three make the bundle's maintenance posture your problem.
Weaver
How can I help you explore Laravel packages today?