Core Bundle Laravel Package

Product Decisions This Supports

• CMS build vs. buy: Establishes whether structured content management is a differentiator worth building. This package is a reference implementation, not a viable dependency—useful for informing the decision, not for shipping.
• Framework fit on the roadmap: Confirms this is a Symfony bundle, not a Laravel package. Any Laravel roadmap that assumes drop-in compatibility is mis-scoped; treat it as a cross-framework integration risk, not a Composer install.
• Legacy maintenance and replacement planning: If the organization already runs Unite CMS, this supports a maintain/fork/replace analysis and identifies the core components (domains, content types, field types, permissions, GraphQL) that a replacement must cover.
• Requirements research: Serves as a domain-model reference for content types, field abstractions, and multi-tenant domain boundaries—useful for writing requirements or evaluating vendors, not for production.
• Sourcing and prioritization: With minimal adoption, zero dependents, and no release since January 2020, it does not justify roadmap capacity or engineering time for new products.
• Architecture options: Supports the decision between embedding a CMS in the Laravel app versus running a headless CMS as a separate service consumed over HTTP/GraphQL.

When to Consider This Package

Consider only when:

• You already operate a Unite CMS or Symfony application that depends on this bundle and need to assess maintain, fork, or replace.
• You are conducting a time-boxed due-diligence or architecture teardown and will not ship it as a dependency.
• You need a reference model for CMS concepts—content types, field types, domain scoping, permissions—to inform requirements or vendor comparisons.
• Your team will explicitly own a fork, including security review, PHP/framework compatibility, and long-term patching.

Look elsewhere when:

• You are building a new Laravel application. Prefer maintained Laravel-native admin/CMS packages, a maintained headless CMS, or a custom content service.
• You need active releases, security patches, vendor support, or a healthy contributor community.
• You require documented compatibility with current PHP, Laravel, or Symfony versions.
• Content management is not a core differentiator—buying a maintained SaaS or headless CMS is lower risk.
• You cannot absorb a package with minimal adoption, no dependents, and no release since 2020.

How to Pitch It (Stakeholders)

For executives: "This is the legacy core of Unite CMS—a Symfony component, not a Laravel package. With negligible adoption, zero dependents, and no release since January 2020, adopting it creates maintenance and security exposure without strategic differentiation. Recommendation: do not make it a roadmap dependency. If content management is required, evaluate a maintained headless/SaaS CMS or a thin Laravel-native content layer, and budget accordingly."

For engineering: "Treat this as a reference implementation only. It assumes Symfony DI, Doctrine, security, and GraphQL conventions; a Laravel integration would require a substantial bridge with no upstream support. If Unite CMS is genuinely required, run it as a standalone service and integrate over GraphQL rather than embedding it. Any spike must verify framework and PHP version compatibility, license and security posture, and test coverage—and must have a named owner before it goes beyond a spike."