Init Cms Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for page/content authoring. The package supplies an admin UI plus a structured page-data model. The decision it informs is whether to buy a maintained authoring layer or staff an in-house editor. v6.4.14 is a natural re-evaluation checkpoint, because a breaking major with a UI overhaul is the cheapest moment to compare alternatives before sinking migration effort.
• Roadmap scheduling. This is a breaking release, not a patch. It forces a PHP ≥ 8.2 floor and a data-format migration onto the roadmap. Treat the upgrade as a discrete, funded work item with a deadline driven by PHP 8.1 end-of-life, not as opportunistic maintenance.
• Data durability / versioning strategy. Page serialization now runs through the Symfony serializer. That changes how page data is versioned and stored — a product-level risk (content loss or corruption on migration) that needs explicit sign-off before rollout, not just an engineering sign-off.
• Extension and staffing model. Annotations are gone in favor of PHP native attributes. This narrows who can extend the package to engineers current with modern PHP idioms, but improves static analysis, IDE support, and onboarding for new hires. Affects hiring and contractor briefs.
• Editor UX and change management. The redesigned UI is a user-facing change for internal content editors. Plan retraining, refresh screenshots and help docs, and re-run accessibility review.
• Use cases unlocked: marketing/landing-page authoring by non-engineers, structured page content with a consistent schema, and page data that can be versioned per release.

When to Consider This Package

Adopt when:

• The team is on Laravel and can commit to a PHP 8.2+ runtime in the near term.
• You need editor-facing UI and structured page data, not a fully bespoke CMS.
• You can absorb a migration cycle: existing page payloads must round-trip through the new serializer and be verified before cutover.
• You have capacity to re-audit custom admin views and any theme/CSS overrides after the UI rebuild.

Look elsewhere when:

• Production is pinned to PHP 8.1 or below and the platform team will not move — you are blocked, full stop.
• You have substantial customization built on the old annotation-based extension points; the rewrite cost may exceed the cost of switching.
• You need a stable, non-breaking API posture (an LTS-style dependency) rather than a package that ships breaking majors.
• Stored page data is complex or high-volume enough that the serializer change becomes a data-migration project you cannot fund or test adequately.
• You rely on the admin UI as a system of record for non-technical staff and cannot tolerate a simultaneous UI change and data-model change in one release.

How to Pitch It (Stakeholders)

For executives: This package is our page/content authoring layer. Version 6.4.14 is a major upgrade — it modernizes the editor interface and the underlying page data format, but it requires us to be on PHP 8.2 or newer and to rework any customizations we have built on top of it. Recommendation: treat this as a planned migration with a defined window, not an opportunistic version bump. Cost is engineering time for migration plus QA of existing page content; benefit is staying on a maintained package with better editor UX and cleaner long-term data versioning. I need a decision on timing and on whether we re-evaluate alternatives before committing.

For engineering: Breaking release; four things to scope. (1) PHP 8.2 minimum — coordinate with platform/infra and confirm the runtime upgrade lands first. (2) UI rebuilt — audit custom views, themes, CSS overrides, and any screenshot-based docs or E2E tests. (3) Annotations replaced by PHP native attributes — all custom registration and configuration code must be rewritten; mechanical but broad, so estimate by count of extension points. (4) Page serialization now uses the Symfony serializer — verify existing page payloads deserialize correctly, add round-trip and fixture tests, and confirm the storage/versioning contract before rollout.

Suggested next step: a time-boxed spike branch to measure blast radius across (2) and (3), with a written read on (4)'s data-migration risk, then a staged rollout behind a flag.