Variants Field Bundle Laravel Package

Product Decisions This Supports

• Content modeling / schema design: This package adds a field type that lets an editor pick one of several predefined field-group variants at a single field position. That directly supports a "flexible section" content model — e.g., a page section that can render as a hero, a CTA, or a gallery, each with its own set of fields — without multiplying content types or building a custom picker.
• Build vs. buy (small scope): If the product need is "editors choose among N variant field sets," this is a pre-built field type rather than a custom internal tool. The buy case is narrow and only applies inside an existing Unite CMS install.
• Roadmap input for editorial flexibility: Informs whether to invest in component/block-based authoring (variant selection, per-variant validation, design-system-aligned blocks) versus a fixed template model.
• Use cases: Marketing landing pages with swappable section types; design-system-driven content where the component choice implies a distinct field schema; multi-brand/multi-locale templates that share a slot but differ in fields.
• Important caveat for decisions: Adoption signals are effectively zero (no stars, no dependents, score 0). Do not let roadmap or platform decisions hinge on this package; treat it as an option to evaluate, not a dependency to plan around.

When to Consider This Package

Consider it when all of the following hold:

• You are already running Unite CMS. Note the stack mismatch: this is a Symfony bundle, not a Laravel package — it will not drop into a Laravel app without the Unite CMS runtime.
• You need field-level variant selection and want to avoid writing a bespoke field type.
• You can absorb ownership risk: audit the source, pin the version, and be prepared to fork or vendor it if upstream goes quiet.
• The variant logic is isolated to CMS configuration, so it can be swapped out without touching application code.

Look elsewhere when:

• You are on Laravel and using Nova, Filament, or a custom admin — use native repeater/builder/block fields or a polymorphic content approach instead.
• You require maintained dependencies, security review, release cadence, or vendor support (SLAs) — none are evidenced here.
• A single flexible "block" field or polymorphic content types already cover the requirement; variant selection may be over-modeling.
• The variant set is likely to change often; per-variant field groups can multiply schema maintenance and migration work.

How to Pitch It (Stakeholders)

To executives: This is a small add-on for Unite CMS that lets editors choose between predefined sets of fields, so one content slot can behave like several different components. It could reduce custom development for flexible page layouts. However, it has essentially no adoption or maintenance signals (no stars, no dependents, no score), so I'd frame it as a low-cost spike, not a platform commitment — approve a time-boxed evaluation, not a dependency.

To engineering: Symfony bundle extending Unite CMS's field-type system; the value is a variant selector with per-variant field groups. Before adoption we need a code and license review, confirmation it matches our Unite CMS version and upgrade path, and a fork/vendor plan if upstream is inactive. Risk is low if confined to CMS configuration and reversible; high if it becomes the backbone of our content model. Please also confirm we aren't actually a Laravel shop expecting a Laravel package — this isn't one.