Statamic Feedback Laravel Package

Technical Evaluation

What this is: Despite being described as a Laravel/PHP package, the release notes describe a Statamic addon (Control Panel, Antlers tag, collections/entries, multi-site origin IDs, Statamic preferences system). Treat the assessment as "Statamic 4/5 addon installable via Composer into a Laravel app," and confirm that assumption early — it materially changes the stack-fit answer.

Architecture fit: Strong for teams already on Statamic. It reuses native primitives rather than bolting on a parallel system: flat-file YAML storage matches Statamic's content model, permissions map to existing roles, notification preferences use the built-in preferences store, and the frontend widget ships as a single Antlers tag. There is no new database, no new service, and no new auth surface — a genuinely low-friction footprint.

Integration feasibility: High on paper. Composer install, publish config, set storage path, grant role permissions, drop the tag in a layout. No migrations, no queue workers, no external dependencies to provision. The frontend tag and the CP-side views are the only touchpoints.

Technical risk:

• v1.0.0 is the first release. There is no upgrade history, no deprecation track record, and no evidence of production hardening. Semver gives 1.x stability guarantees, but the initial release should be treated as unproven.
• Flat-file YAML storage is the dominant risk. Feedback volume is unbounded and write-heavy; every comment, read-mark, and resolve action rewrites YAML. Listing views, unread badges, and the injected feedback-count column imply repeated reads/parses of the whole store. This is fine at hundreds of items, questionable at tens of thousands.
• Ephemeral/local storage breaks the model. In containerized, autoscaled, or serverless deployments, feedback written to local disk is lost or invisible across nodes. Requires a shared/persistent volume and a stateless-app exception in the platform design.
• CSS-selector pinning is structurally fragile. Pins break silently whenever frontend markup or class names change. No mention of selector re-validation, orphan handling, or pin re-anchoring.
• Screenshot capture depends on browser secure-context and screenshot APIs, with per-browser and cross-origin iframe limitations. Failures are client-side and hard to diagnose. Storage location and size limits for captured images are unspecified.
• Multi-site via origin entry IDs is a sensible design but introduces a resolution step that can fail when entries are unlinked, localized differently, or deleted.
• Content-repo hygiene: feedback YAML inside the project's storage path may land in Git-based content deployment pipelines, producing noise or accidental overwrites.

Key questions:

1. Which Statamic and Laravel versions are supported, and is there a stated support/EOL matrix?
2. Does the package require Statamic, or does it also work in a plain Laravel app?
3. Where are screenshots stored, in what format, and is there a size/quota/retention control?
4. What is the read/write performance profile of the YAML store at 1k / 10k / 100k feedback items?
5. How are pins handled when selectors no longer match — orphaned, hidden, or surfaced for repair?
6. Is the addon licensed/paid, and does it require a license key or phone-home validation?
7. Does feedback YAML live inside the content/Git deployment path by default, and can it be relocated out?
8. What are the stated backward-compatibility commitments for the 1.x line?

Integration Approach

Stack fit: Assume Statamic 4/5 on Laravel 10/11, PHP 8.1+, standard Composer-based deploy. The addon is additive — no schema changes, no service container overrides, no auth provider changes. It sits alongside content modeling rather than interfering with it.

Migration path: There is nothing to migrate from — this is greenfield adoption. The only "migration" is organizational: introducing a feedback workflow where none existed, and deciding where the YAML store lives relative to the content repository.

Compatibility checks before commit:

• Pin the Statamic/Laravel/PHP versions and confirm the addon's constraint range in composer.json.
• Verify the storage path is writable by the PHP user and is on persistent, shared storage in every environment.
• Confirm the addon's permission set is exposeable through existing roles without modifying core role definitions.
• Confirm screenshot capture works behind the CDN/proxy and on the HTTPS domain(s) actually in use.
• Verify the frontend Antlers tag renders correctly inside the site's layouts, partials, and any caching layer — full-page or edge caching will need a carve-out.

Sequencing:

1. Spike (1–2 days): install in a scratch environment, exercise the widget, pins, screenshots, mentions, and resolve flow; confirm Statamic version compatibility.
2. Storage decision: choose the feedback path explicitly — persistent volume, or a path outside the content repo. Document backup and restore for it before any real use.
3. Permissions and notifications: map the four permission levels to existing roles; validate email/toast behavior against team preferences.
4. Pilot on one site/locale: run with a small group for two to four weeks, measuring store size and CP listing responsiveness.
5. Frontend rollout: add the tag to shared layouts once pin-selector conventions (stable data- attributes) are agreed with the frontend team.
6. Multi-site expansion: only after origin-entry linking is validated on a second site.

Operational Impact

Maintenance: Low in the steady state — no database, no migrations, no cron. The recurring work is upgrading the addon alongside Statamic majors and managing the YAML store's growth. The unpriced cost is selector maintenance: every frontend template refactor is a potential pin-break event, and someone must own repairing or retiring orphaned pins.

Support: Requires support from both the content/CP administrators (feedback triage, permissions) and the platform team (storage, backups, version upgrades). Add a runbook entry for "feedback store corrupt/unreadable" and for "screenshots failing to capture" — both are plausible first-line tickets with non-obvious causes.

Scaling:

• Vertically fine, horizontally awkward. Single-server deployments are the natural home. Load-balanced or autoscaled setups need shared storage configured correctly, or feedback silently fragments per node.
• Store growth is the ceiling. YAML rewrite-per-change plus full-store parsing for listings and badges makes the CP the likely first bottleneck, not the frontend.
• Screenshots are the unknown scaling factor — image volume, not record count, may dominate disk usage.
• Frontend caching may need per-page exceptions since the widget state is user- and page-scoped.

Failure modes to plan for:

• Write permission loss or storage path misconfiguration → silent feedback loss or hard errors on submit.
• Ephemeral container filesystem → feedback vanishes on redeploy.
• DOM/markup change → pins detach; feedback remains but loses its visual anchor.
• Browser screenshot API unavailable or denied → attachment silently missing.
• Concurrent writes to the same YAML file → last-write-wins data loss under simultaneous editors.
• Entry deletion or relinking → multi-site feedback orphans.
• Content deploy pipelines overwriting the feedback directory.

Ramp-up: Short for Statamic-fluent developers — install, configure, and integrate in roughly half a day. Non-trivial for the organization: it introduces an entirely new review workflow (pins, mentions, resolve lifecycle, unread state) that teams will either adopt enthusiastically or ignore. Budget for a short internal demo and a written convention on what belongs in feedback versus the normal content workflow. Because this is v1.0.0 with no public track record, plan for the possibility of a fast-follow patch release within the first quarter and keep the addon version pinned.