Statamic Button Box Laravel Package

Technical Evaluation

What the package actually is. rias/statamic-button-box is a Statamic addon that provides a Control Panel fieldtype: instead of a dropdown or radio list, editors pick from a set of rendered buttons. "Create beautiful choices for your clients" is an accurate description — it is an editorial UX affordance layered over a scalar field value. There is no data store, no API surface, no front-end rendering, no query layer. This scope is the most important fact in the evaluation, because it caps both the upside and the blast radius.

Architecture fit. The package is only meaningful inside a Laravel application that already runs Statamic. It follows standard addon conventions: a service provider registering the Fieldtype, a Vue component for the publish form, and a config/options array declared in the blueprint. Stored values are content-file YAML like any other fieldtype. If the estate is Laravel-without-Statamic, or Statamic is being evaluated rather than already adopted, this package is not a factor in the decision — it is a garnish, not an ingredient.

Integration feasibility. High, and cheap. composer require, addon registration, then swap type: select for type: button_box in a blueprint or fieldset and supply options. Realistic effort is hours of developer time, dominated by verifying the version matrix rather than by the integration itself. This is a one-ticket change, not a workstream.

Technical risk. Low severity, moderate uncertainty.

• Contained blast radius: presentational only. No migrations, no auth, no queue, no outbound network calls, no user-input processing. Worst case is a degraded editing experience, not a security or data-integrity incident.
• Volatile integration surface: the CP component is the fragile part. Statamic has changed its Control Panel JS stack across majors (notably the Vue 2 → Vue 3 transition), and small fieldtype addons are the first to break. This is the single realistic failure vector.
• Unproven and thinly maintained: 2 stars, 0 dependents, effectively a single-maintainer community package. Bus factor is 1. There is no evidence of a meaningful test suite, and the declared Statamic/Laravel version constraints need to be read directly from composer.json rather than inferred.
• Opportunity score of 30.97 correctly signals limited business leverage. This is polish, and should be resourced and governed as polish.

Key questions to close before adoption.

1. What is the supported Statamic/Laravel version matrix, and does the pinned release match our CMS version exactly?
2. Is the stored value a plain string identical to what a select fieldtype would persist? (If yes, the change is reversible and content stays portable.)
3. Does it work inside Replicator, Grid, and Bard sets — the common failure point for small fieldtypes?
4. Does it support option labels distinct from values, defaults, and required/conditional validation?
5. What happens to the editorial UI if the addon is removed or breaks — does the field fail silently or loudly?
6. License terms and the maintainer's stated support/succession posture.

Integration Approach

Stack fit. Adopt only if Statamic is already the CMS. There is no partial-fit scenario: the package cannot be used in a plain Laravel admin, and it does not improve anything an application-owner would see.

Migration path. Minimal and reversible, which is the strongest argument for trying it. Introduce it first as a new field on a low-traffic blueprint rather than converting existing fields. Because the underlying stored value should be equivalent to a select, converting an existing field is a blueprint YAML edit with no content rewrite — and rolling back is the same edit in reverse. Verify the value serialization on staging before assuming that reversibility holds.

Compatibility. Pin the addon version explicitly in composer.json rather than floating it; an abandoned-but-pinned package is an annoyance, an abandoned-but-floating one is an incident. Confirm the addon ships prebuilt CP assets so it does not impose a Node build step on the host application. Confirm the fieldset compiles and the publish form renders before touching production blueprints.

Sequencing.

1. Read composer.json and the source directly — version constraints, license, stored-value format. Half a day, and it settles most of the risk.
2. Spike on staging: two or three representative option sets, including one inside a Replicator or Grid if those are in use.
3. Editor UAT on a single low-traffic section; confirm the buttons map to the same values editors already understand.
4. Roll out fieldset by fieldset, not as a big-bang blueprint change.
5. Document the revert path (change type back) and the pinned version so a future upgrade does not silently strand it.
6. Set an explicit trigger for forking/vendoring: if a Statamic major lands and the addon is not updated within a defined window, fork it internally or remove it.

Operational Impact

Maintenance. Low routine cost, with a known spike on Statamic majors. The realistic budget is a few hours per CMS upgrade to verify the CP component still renders, plus normal composer update hygiene. The material risk is not effort — it is that nobody notices the fieldtype has broken until an editor reports a blank field.

Support. No vendor SLA. Upstream support is GitHub issues on a 2-star repository with one maintainer; assume self-service. The internal owner should be whoever owns the CMS, and they should be able to read the fieldtype source — it is small. The larger support cost is editor-facing, not developer-facing: buttons invite more "which one do I pick" questions than a dropdown, so pair the rollout with a short note in the editorial docs. For a tool literally pitched at "your clients," that is the recurring cost to plan for.

Scaling. Negligible. Control Panel only — no front-end query, no caching implications, no effect on request latency or content API throughput. It scales with the number of editors, not the number of requests, and editor counts are small.

Failure modes.

• CP asset breakage after a Statamic upgrade — most likely failure. Field renders blank or unusable; editors blocked on that one field. Mitigation: staging upgrade rehearsal, version pin, named owner.
• Silent removal or abandonment — value persists in content, editor UI disappears. Content remains intact and readable, but editing regresses with no alert. Mitigation: fork-or-remove decision date.
• Option/value drift — renaming an option value orphans stored content. Identical hazard to a native select; not introduced by this package, but button grids make it easier to forget that labels and values are separate.
• Supply chain — near-zero exploitability given no user input handling or network calls, but an unmaintained entry in composer.lock is still an unmaintained entry. Periodic review, not active monitoring.

Ramp-up. Developers: hours. Editors: low to moderate, and mostly about confidence rather than capability — the buttons must be visibly equivalent to the choices they replaced. Given the 30.97 opportunity score, the correct posture is a cheap, reversible, well-pinned trial on one section, treated as UX polish rather than a dependency worth architecting around.