Visual Editor Laravel Package

Product Decisions This Supports

• Editorial-experience roadmap. Decides whether to invest in "click the rendered page, edit the field" instead of the current CP hunt-and-peck. Directly attacks the support-ticket class "where do I change this headline?" and the failure mode where editors abandon Live Preview and edit blind.
• Build vs. buy for visual/inline editing. The hard parts — preview overlay, DOM morphing, CP↔preview bridge, per-set UUID targeting, per-field targeting, Antlers/Blade tag parity — already exist here. Evaluating it as a spike is far cheaper than writing a spec for those from scratch, even if you ultimately build or fork.
• Scoping template annotation work as a line item. Cost is bounded and estimable: one {{ visual_edit }} on the outermost element of each set partial, or field="handle" on markup that already exists. That's a per-template estimate you can put in a roadmap, not a rewrite.
• A genuinely low-risk rollout lever. The tag emits raw data-* attributes only inside Live Preview and nothing outside it. That makes "annotate everything now, decide later" a safe pattern and supports a pilot on one section of the site with no production fallout.
• A product call on hidden content. Optional preview-only placeholders (SEO title/description, grouped sub-fields) let you decide whether invisible content becomes visually editable or stays CP-only.
• Explicitly not supported: content migration, fieldset restructuring, or _visual_id migration. Those surfaces are declared locked, so any migration/refactor programme should not assume this addon survives it.

When to Consider This Package

Consider it when:

• You're on Statamic with Live Preview actually in use, and you own the templates (Antlers or Blade).
• The pain is "editors can't find the field," not "editors can't see the result" — native Live Preview already solves the latter.
• You can fund a sandbox spike and name a maintenance owner, and you have a small set of high-traffic templates worth annotating first.
• You're buying a developer/editor-experience layer, not content-critical functionality.

Look elsewhere when:

• Signal is thin. 1 star, 0 dependents, no adoption history, single maintainer, appears pre-1.0. Treat it as a reference implementation to learn from, not a supply-chain commitment.
• Your content model churns. Fieldsets, Replicator/Bard sets and _visual_id migration are explicitly off-limits — a strong hint that upgrades won't be self-serve.
• You need to change behaviour, not appearance. The preview/overlay/bridge/dock kernel, the postMessage types, the data-sid/data-sve-* contract and the {{ visual_edit }} output are locked. Panel styling and copy are fair game; anything that changes how the editor works is not. If your roadmap requires that, you inherit a dependency you can't patch.
• Your build pipeline can't tolerate dist fragility. The editor ships as prebuilt hashed assets where addon.js must import the exact overlay-host-*.js hash; a routine Vite build can silently delete it and the editor vanishes. vendor:publish of the dist is forbidden.
• You're not on a compatible Statamic version. The addon is pinned to native fieldtype/CP behaviour it deliberately refuses to wrap or subclass.
• Ongoing vendor risk isn't budgeted. Assume fork-and-maintain, or accept it may stop tracking Statamic releases.

How to Pitch It (Stakeholders)

Executives. "Today editors look at a page, then go hunting for the matching field in the control panel. This makes the page itself the editing surface — click the headline, edit the headline — and it ships nothing to production, so there's no performance or SEO exposure. Treat it as an editorial-speed and CMS-training play: faster publishing, fewer support tickets. To be clear on maturity: it's an unproven addon, one maintainer, no adoption yet, so we'd validate it in a sandbox against two or three real templates before committing."

Engineering. "It's a Statamic addon that injects data-* annotations during Live Preview only, and emits nothing otherwise. Adoption cost is one tag per set partial or per field, in templates we already own, in both Antlers and Blade. The constraints are real and non-negotiable: the preview/overlay/bridge kernel, the postMessage protocol and the prebuilt resources/dist bundle are locked — hashed asset names must stay in sync, vendor:publish of the dist is a no-go, and an ordinary rebuild can take the whole editor down. Cosmetic and copy changes are safe; behavioural changes are not. Budget for us owning a fork if we adopt."