Statamic Extended Section Laravel Package

Technical Evaluation

Architecture fit. appswithlove/statamic-extended-section is a Statamic addon, so it slots into the standard Laravel package lifecycle: Composer install, auto-discovered service provider, config/asset publishing. Critically, it is a Control Panel / authoring-layer extension, not a runtime or rendering dependency. That is the best possible architecture fit for a low-adoption package: the blast radius of failure is confined to the editor experience, not to page delivery, data retrieval, or the request path. No database, no queue, no external service, no cron.

The package extends Statamic's native "section" concept — the tab-group abstraction in the publish form. That means it is coupled to Statamic's internal Vue/CP component API, which is the least stable surface in the Statamic ecosystem (Vue 2 → Vue 3, Tailwind and Vite build changes across v3 → v4 → v5).

Integration feasibility. High in effort terms — likely measured in hours, not sprints. The two questions that gate it are not effort but value and content-safety:

• Does it change what is written to the YAML/Markdown content files, or is it purely presentational in the CP? Presentational = reversible and low-risk. Content-schema change = every entry becomes a migration surface and plain Statamic may no longer parse it.
• Which statamic/cms constraint does it declare? A CP addon two majors behind its CMS is effectively dead.

Technical risk. Adoption is essentially zero (4 stars, 0 dependents), so there is no community validation, no secondary maintainer, and no evidence of upgrade cadence beyond a single recent release. The opportunity score (16.7) implies a real capability gap; the adoption data implies no one has stress-tested it. Assume single-maintainer/agency-tool risk and budget for a fork.

Key questions for the sponsor/vendor:

1. What specific authoring pain does this solve that native sections + fieldsets + a tab layout cannot? Is that pain ours today, or hypothetical?
2. Purely CP presentation, or does it write additional keys into content files? Can the content be read by vanilla Statamic if the addon is removed?
3. Supported Statamic major/minor range, and what is tested in CI?
4. Does it respect Statamic's role/permission system for section visibility?
5. Does it compose with Bard/Replicator and nested fieldsets — the places sections actually matter?
6. License terms and maintainer willingness to accept PRs; would they accept us as a co-maintainer?
7. Is there a native equivalent landing in a Statamic release we could wait for instead?

Integration Approach

Stack fit. Laravel + Statamic + Composer, deployed as a composer.lock delta. No infrastructure, no environment variables, no data store. It fits our existing build-and-deploy pipeline without a new operational surface, provided the statamic/cms version constraint is pinned and tested.

Migration path. Run it as an additive layer. Keep every blueprint usable with native sections, so rollback is "remove the package, revert the blueprint YAML, clear cache" with zero content remediation. If step one reveals content-format changes, stop and treat it as a data migration with a full entry audit before any production write.

Compatibility. Three things to verify before adopting: pinned Statamic minor version alignment; no CP asset/build collisions with other addons or our custom CP theme (Tailwind/Vite version conflicts are the most common failure here); and behavior when the Stache and view caches are cold — clear caches on deploy as a rule.

Sequencing.

1. Spike (half a day): install into a throwaway Statamic instance on our version, read the source, diff the content file before/after to answer the schema question definitively.
2. Value gate: confirm the CP gap exists and is painful enough to justify a single-maintainer dependency. If not, close it out.
3. Staging pilot on one collection with two or three sections; internal authors exercise it.
4. Content-safety check: remove the addon in staging, confirm entries still load and publish-form still functions.
5. Production on that one collection for two weeks; watch for CP console errors.
6. Broaden blueprint by blueprint. Decide at step 3 whether to vendor-fork under our own namespace — given the adoption numbers, a fork we control is the more honest long-term posture.

Operational Impact

Maintenance. Low absolute surface area, high ownership risk. The realistic model is that we become the de facto maintainer: patch it ourselves on Statamic majors, or carry a fork. Budget roughly 1–2 days per Statamic major upgrade plus occasional dependency bumps — small, but it lands on a specific person, so name them.

Support. GitHub issues only, no SLA, no vendor escalation path. Secondary support is the Statamic Discord community, which will have little experience with this package given the dependent count. Treat internal ownership as the support model from day one.

Scaling. Negligible on the delivery path — it does not execute per request, so front-end page performance is untouched. The scaling concern is editor-side: publish-form load time grows with the number of sections and fieldset complexity on a single blueprint. Measure CP load with the target blueprint before rolloing out broadly; if authoring is already slow on large collections, this adds to it rather than relieving it.

Failure modes.

• Statamic upgrade breaks the CP Vue component. Likelihood moderate per major, severity high — editors cannot publish, and it is not caught by front-end tests.
• Silent content-format drift. Content written with addon-specific keys becomes unreadable or lossy without it. Severity high because it is discovered late, on rollback.
• CP asset conflict with another addon or theme build. Low severity, confusing to diagnose.
• Abandonment — no release compatible with the next Statamic major, forcing an emergency fork on someone else's timeline.
• Permission gap — extended sections rendering for roles that should not see them, if the addon does not integrate with Statamic's permission system.

Ramp-up. Editors: minimal — it is a UI enhancement, a 15-minute walkthrough and one page of internal docs. Developers: moderate — one engineer should read the source end-to-end (half a day to a day) to become the owner, including the build pipeline and the content-write path. That ownership step is not optional given the maintenance profile.

Recommendation. Adopt only against a concrete, named authoring pain, and only as a pilot with an explicit rollback and a named owner. Score it as an internal fork candidate, not a durable third-party dependency.