Statamic Inline Edit Laravel Package

Technical Evaluation

What this package is (inferred from the release): statamic-inline-edit is a Statamic addon that adds in-place front-end editing to a Statamic site — an editor-facing control panel/bar, per-field edit affordances, a rich text editor, a markdown source box, a small settings panel (select, date input, switch), and save/status messaging. It is a Composer package with published front-end assets, so it sits in the "editor experience / CMS tooling" layer rather than in application domain code.

Architecture fit: Low architectural coupling. It lives entirely in Statamic's addon layer, ships Blade/JS/CSS into public/vendor/, and requires no schema, queue, or service changes. That makes it a cheap capability to adopt and a cheap one to remove — good for a package we might pilot with a content team before committing.

Integration feasibility: Improved by this release. composer require is now the whole install on a standard Statamic site, which removes the "run an extra publish command and remember it in every environment" step that usually causes drift between local, staging, and production. The legacy statamic-inline-edit-assets tag is retained, so existing installs are not forced to change on upgrade.

Technical risk — the material item is --force publishing. Front-end files are now published under statamic-inline-edit and Statamic republishes that tag with --force after statamic:install. Consequence: any hand edit to public/vendor/statamic-inline-edit/ is wiped on every composer install / composer update. This is not a breaking API change, but it is a breaking operational change for any team that customized the editor by editing published files — a very common pattern for a package like this. Styling must move into our own stylesheet, and we should assume any customization currently committed under public/vendor/ is at risk.

Secondary risk — accessibility behavior changed, mostly for the better. Focus rings, focus return after Escape/Enter and after panel close/reload, aria-labelledby naming for the small-panel controls and markdown source box, and role="status" live region for save/error messages. Net positive for WCAG 2.1 AA posture (2.4.3 Focus Order, 2.4.7 Focus Visible, 4.1.3 Status Messages), but it does change observable keyboard behavior, so it needs a regression pass rather than a blind bump.

Key questions for engineering:

• Which Statamic and Laravel/PHP versions does 1.11.1 declare, and is there a supported-version matrix in the repo? The release notes don't say, and that determines whether we can adopt it on our current stack or must wait.
• Do we currently have any hand edits under public/vendor/statamic-inline-edit/ (committed, gitignored-but-present, or applied by a deploy script)?
• Does our deploy pipeline run statamic:install on every release, or only first install? That determines whether --force hits production or only CI.
• Is there a documented CSP/asset-pipeline story (CDN, cache-busting) for the published bundle, since filename-stable republishing can leave stale assets cached at the edge?
• Is the addon's editor surface covered by any test we own — a smoke test of "edit a field, save, see status" — or is it entirely manual QA?

Integration Approach

Stack fit: Statamic-flavored Laravel. There is no migration, no model, no persistence surface of its own — it reuses Statamic's content APIs and its own front-end bundle. It fits anywhere we run Statamic for marketing or docs content, and does not fit headless/API-only or non-Statamic Laravel apps. It is orthogonal to our application services, so it can be piloted on one site without a platform decision.

Migration path: Two-track.

1. Adoption (new site): composer require, confirm the statamic-inline-edit tag publishes during install, done. This is now a one-line install and should be treated as low-ceremony.
2. Upgrade (existing site): first extract any custom CSS out of public/vendor/statamic-inline-edit/ into our theme stylesheet and delete the in-vendor edits; then bump the package; then confirm which publish tag actually ran. Doing the style extraction before the version bump means the --force republish is a no-op rather than an incident.

Compatibility: Backward compatible at the install layer — the old statamic-inline-edit-assets tag still works, so a pipeline that references it won't break on day one. Behavioral compatibility is the softer edge: focus now moves on Enter/Escape and on mode toggle, and status messages are announced. Any internal keyboard-shortcut documentation, editor onboarding deck, or QA script that describes the old behavior is now slightly wrong. MARKETPLACE.md dropping out of the Composer package is inert unless an internal doc links to it inside vendor/.

Sequencing:

1. Inventory public/vendor/ and deploy scripts for hand edits (blocking).
2. Port custom styling into our own stylesheet; verify visually in staging.
3. Upgrade the package; verify the publish tag and that --force overwrote only files we don't own.
4. Keyboard + screen-reader pass on one representative content type: tab to first field, Enter opens, Escape returns focus, save shows a full wrapped status, error path announces.
5. Update editor-facing docs and the QA checklist; then roll to remaining sites.

Operational Impact

Maintenance: The --force model is actually a maintenance simplification if we accept the boundary: we own our stylesheet, the package owns public/vendor/. The failure case is a team that doesn't accept the boundary and keeps patching vendor files — they will re-patch after every dependency update and never notice until a style regression ships. Budget a one-time cleanup and add a lint/review rule: no commits under public/vendor/.

Support: Expect fewer editor tickets, not more. The fixes here — visible focus on narrow fields, focus not jumping to the top of the page, named controls, full error text instead of a 40-character truncation, role="status" announcements — target the exact complaints that generate "I can't tell what I'm editing" and "it said something but I didn't catch it" tickets. Error text wrapping also removes a real support ambiguity: truncated saves messages were previously unactionable for editors reporting failures to us.

Scaling: No runtime scaling dimension. It's static assets plus editor-side JS; cost is per-editor-session and negligible. The scaling concern is content-team scaling — more editors across more sites means more keyboards, more screen readers, more narrow viewports, so the accessibility work is what makes broad rollout defensible.

Failure modes:

• Silent style reset: composer update clobbers customized vendor assets; the site still works, so nobody notices until an editor complains or a brand review catches it. Highest-probability failure.
• Stale CDN assets: republished files with stable names behind a cache; editors see old focus behavior and file accessibility bugs that are already fixed.
• Partial publish: a site where statamic:install doesn't run (or runs without the tag) ends up with a package that loads but no styles/JS — looks like a broken editor, is actually an install gap.
• Keyboard regression in our own overlay/modal code: the addon now returns focus after a control-panel overlay closes; if our theme also manipulates focus, we can get a fight over focus target. Worth a targeted test if we have any custom modals on content pages.
• Version drift across sites: mixed 1.11.x and earlier versions mean editors get different keyboard behavior per site — confusing in a multi-site estate.

Ramp-up: Low. For editors it's a no-learning-change upgrade with better feedback. For engineers, the only new knowledge is the publish tag and the --force rule — roughly an hour of onboarding plus the style extraction. The larger cost is the accessibility QA pass, which is worth doing once and turning into a reusable checklist rather than repeating per site.