Chief Laravel Package

Product Decisions This Supports

• Roadmap: multisite/multi-brand expansion. 0.10.0 moves multisite behaviour into the core rather than an add-on, which turns "one site per install" into a first-class product capability. This is the release that lets you commit to a multi-domain, multi-locale, or multi-brand roadmap without a bespoke forked CMS.
• Build vs. buy for content modelling. Refactored fragments and urls are the primitives you would otherwise hand-build for reusable content blocks and localized/redirectable routing. Choosing Chief here is a bet that a maintained package covers those primitives better than an internal CMS layer.
• Use cases now in scope: regional storefronts or landing pages sharing one content base, agency/whitelabel setups where each client site is a tenant, and content that must be reused across domains with per-site URL structures.
• Migration cost is now a plannable line item, not an unknown. The published upgrade guide plus an upgrade command that autofixes common breaking changes converts "we'll have to rewrite fragments and URLs" into a bounded, scriptable task — which is what makes it defensible to schedule the upgrade in a sprint rather than a quarter.
• Sets the constraint for the next 1–2 releases. Because this is a 0.x minor with explicit breaking changes, the product plan should assume at least one more migration event before 1.0; avoid coupling launch-critical deadlines to a Chief version bump.

When to Consider This Package

Adopt when:

• You are on Laravel and want a CMS that lives inside your application rather than beside it — content modelling, routing, and admin in one codebase.
• Multisite is a real, near-term requirement (multiple domains/locales from one install), and you want that behaviour supported in core rather than patched per project.
• You have engineering capacity to absorb a documented breaking-change cycle: read the upgrade guide, run the upgrade command, verify fragments and URL generation, and regression-test routing and redirects.
• Your team is comfortable pinning versions and testing upgrades on a branch before merging — the release includes an autofix command, but autofix output still needs review.

Look elsewhere or defer when:

• You need a stable public API with long-term support guarantees. At 0.10.x the package is still pre-1.0; semver permits breaking changes on minor bumps, and this release is exactly that.
• You have no multisite need and are already stable on 0.9.x — the value is concentrated in multisite and the fragment/URL refactor, so the migration cost buys you little.
• Your content is highly custom or regulated in ways that make a package upgrade a compliance event; prefer a CMS with a formal LTS policy.
• You cannot allocate QA time to URL and redirect behaviour — URL refactors are the classic source of silent SEO and deep-link regressions.

How to Pitch It (Stakeholders)

For executives: The CMS package we depend on has shipped a release that makes multisite a core capability — one install can now serve multiple domains, brands, or regions. That directly enables the expansion work on our roadmap without building a bespoke multi-tenant content layer. The trade-off is that this version changes how content fragments and URLs are structured, so we need a scheduled upgrade with QA on routing and links. The vendor has published an upgrade guide and an automated fix command, which materially reduces the effort and risk versus a manual migration. We remain on a pre-1.0 package, so we should expect one more migration before it stabilises and should not pin a launch-critical date to a version bump.

For engineering: 0.10.0 is a breaking minor: fragments and URLs are refactored, and multisite behaviour has moved into the core. Plan a dedicated branch, run the provided upgrade command to autofix common breaking changes, then treat the guide as the source of truth for the remainder. Priority verification areas are URL generation, redirects, and any fragment reuse across sites — these carry SEO and deep-link risk. Pin the version, upgrade outside a release freeze, and add a routing/redirect regression suite if we don't have one, since we should assume another breaking minor before 1.0.