Visual Editor Laravel Package

Technical Evaluation

What the package is. A Statamic addon that layers a click-to-edit overlay onto Statamic's Live Preview. Templates opt in per element with {{ visual_edit }} (Antlers) or Statamic::tag('visual_edit')->...->fetch() (Blade). The tag emits data-sid / data-sve-* attributes only inside Live Preview and nothing in production, so annotation is nominally zero-footprint.

Architecture fit. Good on paper. It rides Statamic's existing Live Preview and Control Panel rather than replacing them, and the repo's own rules explicitly forbid subclassing, wrapping, or re-registering Statamic fieldtypes and CP Vue components. That is the right posture for an additive authoring layer, and it means the blast radius in application code is one tag per element.

Integration feasibility. The template-side story is genuinely small: add a tag to the outermost element of a set partial, or to an existing <h1> for fixed fields, optionally pass field, blueprint, context, outline-inside. Blade requires {!! !!} (unescaped) — a routine footgun but a documented one. No application-level service wiring or schema work is implied beyond annotations.

Technical risk — concentrated and unusual. The risk is not in the PHP. It is in a prebuilt JS kernel shipped in resources/dist/build, where addon.js imports overlay-host-<hash>.js by exact filename. The repo's own rules state that rebuilding a single input (overlay-host, preview, bridge) can emit a new hash, invalidate the old file, and blank the entire Control Panel editor. vendor:publish of that dist is forbidden; the CP uses a symlink and preview fetches from /!/sve/build/…. Any site with its own asset-publish step, CDN rewrite, or CSP that blocks the preview iframe/postMessage traffic is a candidate for a silent, total failure with no PHP error.

Maturity risk. 1 star, 0 dependents, score 0.005. There is no external validation, no dependant usage to learn from, and no community issue history. The documentation supplied is internal agent-governance material written in Danish (hvornaar-fable.mdc, ve-dist-urorligt.mdc), not user-facing install/upgrade docs. The release chain — npm run cp:build → commit → tag → composer → Packagist — is explicitly reserved for a single individual ("Fable"), making this a bus-factor-one dependency. The _visual_id migration is also a locked surface.

Key questions before any commitment:

• Supported Statamic major/minor and Laravel/PHP matrix? What is the tested upgrade path across Statamic CP releases?
• Is the release cadence guaranteed, or is it one maintainer's spare time? Is there any support contract or SLA?
• Is _visual_id additive/derived, or does annotating content write data that is painful to unwind?
• Does the addon need publishing, a symlink, or a route (/!/sve/build/…) that our hosting/CDN/CSP must permit? Is there a documented check we can run ourselves (analogous to scripts/assert-dist-integrity.mjs) as an adoption gate?
• Do the repo's "never touch Statamic defaults" constraints hold in the released artifact, not just in the working copy?
• Licensing and redistribution terms.

Assessment: technically interesting, operationally immature. Treat as a conditional pilot candidate, not a dependency.

Integration Approach

Stack fit. Only relevant if the estate is Statamic + Laravel with Live Preview in active editorial use. Both Antlers and Blade are supported, so mixed-theme sites are fine, but the blueprint/context conventions differ per template engine and must be documented internally per partial.

Sequencing (recommended):

1. Staging clone, not production. Install with an exact version constraint ("statamic-addon/visual-editor": "x.y.z", never ^), on a cloned site that mirrors the real theme.
2. One collection, three to five templates. Annotate set partials and two or three fixed fields. Verify: overlay appears, click navigates to the right field, set picker opens over the plus, nothing renders in production mode.
3. Failure rehearsal. Deliberately bump Statamic on staging and confirm the CP still loads the editor. This is the single most likely break and the cheapest place to find it.
4. Go/no-go gate. Proceed only if the vendor answers the version-matrix and release-cadence questions and a self-runnable integrity check exists.
5. Widen by surface, one at a time — the repo's own "one surface per task" rule is good operational advice regardless of maintainer.

Compatibility work items:

• Confirm nothing in our deploy pipeline publishes public/vendor/visual-editor or public/vendor/statamic-addon, and that no other addon rebuilds a shared addon.js.
• Verify /!/sve/build/… resolves behind our proxy/CDN and is not blocked by CSP; the editor depends on postMessage between preview and CP.
• Check for CP Vue collisions with any other addon that overrides Statamic field components.

Rollback. Cheap and this is the strongest argument for trying it: annotations are inert outside Live Preview. If the addon is removed, tags must still be stripped from templates, so isolate annotations behind a single shared partial or a feature-flagged include per template family — revert one file, not forty. Avoid the _visual_id migration until it is understood.

Operational Impact

Maintenance. Ongoing cost is editorial discipline plus template upkeep. Every new set partial or fixed field needs a tag; every Bard/Replicator/Grid loop needs one per item and must not double-tag parent and child. That is a convention to encode in a PR checklist, not a one-off install task. Budget roughly one annotation pass per template family, plus re-work whenever a theme is refactored.

Support. Effectively self-support. With zero dependents and one star, there is no community to search and no triage history. Assume we diagnose build-integrity failures ourselves, and that the fastest recovery is reinstalling a known-good composer version — which means version pinning is a hard operational control, not a preference.

Scaling. Server-side load is unchanged: the tag no-ops outside preview. Cost is per-editor page weight in the CP and preview overlay performance, which degrades with the number of annotated elements on a single dense page. Large grids and nested Bard sets are the pressure points. No multi-site or high-concurrency story is documented — an open question for any estate with many concurrent editors.

Failure modes to plan for:

• Blank/absent editor in CP — hash mismatch or missing overlay-host-*.js. Symptom: no error, no toolbar. Detection: synthetic check on CP load after every deploy.
• Silent no-op annotation — tag added outside Live Preview, wrong context, or Antlers colon/dot mismatch (page_info:author vs page_info.author). Detection: author UAT per template.
• Set picker dead — the plus-over-preview path relies on setTimeout(0) mounting and event.source === overlay handling; small timing changes in Statamic break it invisibly.
• Statamic upgrade breakage — CP component changes are the highest-probability regression vector.
• Maintainer unavailability — pinned version is the mitigation; there is no fix-forward option.

Ramp-up. Authors get value fast — click the heading, edit the heading — which is the main reason to pilot. Developers need the dist rules drilled before touching anything: no hand edits under resources/dist, no partial rebuilds, no publishing. Without that discipline, one well-intentioned build step removes the editor for the whole team.

Recommendation. Fund a two-to-three week staging pilot scoped to one collection, with a hard gate on the vendor's version matrix and release-cadence answers. Do not take a production composer dependency, and do not run the _visual_id migration, until the pilot proves the editor survives a Statamic patch upgrade and we have a self-runnable integrity check.