Live Update Laravel Package

Getting Started

Install the package:

composer require marshmallow/live-update

The current release line is v2.6.0 (previous: v2.5.1), so pin to the v2 major ("marshmallow/live-update": "^2.6") rather than the 1.x line an older guide might suggest. Check composer.json for an extra.laravel.providers block; Marshmallow packages generally auto-discover, but confirm before assuming.

Where to look first:

1. vendor/marshmallow/live-update/README.md — still your primary reference, but you now also have a real changelog trail at github.com/marshmallow-packages/live-update/compare/v2.5.1...v2.6.0. Skim the last few minor releases to see what has stabilised.
2. vendor/marshmallow/live-update/src/ — locate the service provider, the public trait or field class, and (as of v2.6.0) the callback wiring. Search the source for callback / Closure to find the exact signature rather than guessing.
3. Verify the package targets your Nova major. Nova 4 vs Nova 5 APIs differ; the v2.x line is the one to validate against your installed laravel/nova.

First use case: Take one throwaway Nova resource (Tag or Category) with a single name field, apply the field/trait, and verify inline editing from /nova/resources/tags saves without opening the detail page. Then immediately exercise the new callback path — pass a closure that logs or mutates a sibling attribute and confirm it fires. Doing both in the smoke test means you catch a broken callback before it silently does nothing in production.

Implementation Patterns

Field-level pattern (primary API). The package centres on an editable field applied inside fields():

use Marshmallow\LiveUpdate\LiveUpdate;

LiveUpdate::make('Title')
    ->onlyOnIndex()
    ->rules('required|string|max:255');

Gate with ->onlyOnIndex() so it doesn't duplicate the detail form.

Trait-on-resource pattern. If your installed version also ships a concern, treat it as an allowlist:

class Post extends Resource
{
    use LiveUpdate;

    public static $liveUpdate = ['title', 'status'];
}

Only add fields you are comfortable mutating from a list view.

Callback pattern (new in v2.6.0). The Feature/fix callback function change means you can attach a closure to run when an inline value is saved — the natural fit for derived state, timestamps, audit logs, and cache busting:

LiveUpdate::make('Status')
    ->callback(function ($model, $value) {
        $model->status = $value;
        $model->published_at = $value === 'published' ? now() : null;
        $model->save();

        Cache::forget("post:{$model->id}");
    });

Because the release note calls it a fix as well as a feature, the previous behaviour was likely broken or had a different signature. If you were relying on an earlier callback, re-read the source for the current argument order and whether the callback is responsible for persisting the model or whether the package saves first. Test both paths: callback that persists, and callback that only reacts.

Authorization wiring. Mirror your PostPolicy::update() check explicitly. Inline editing is a common place for index-level endpoints to skip the authorizedToUpdate flow — verify with a read-only user.

Validation. Confirm rules() on the resource still fire on inline save. If inline saves don't route through ResourceUpdateController, rules won't apply; in that case put ->rules() directly on the field and prove server-side rejection with a test, not just a manual click.

When to fall back. Relationships, file uploads, and JSON belong in a Nova Action or Lens. Inline editing is for strings, enums, booleans, and simple numbers — and callbacks should stay narrow, since they run outside the normal update controller.

Gotchas and Tips

• Pin to the v2 line. "marshmallow/live-update": "^2.6" — v2.6.0 changed callback behaviour, so a loose constraint could pull in a future minor that reworks the signature again. Review the compare link between releases as part of your upgrade routine.
• Callback persistence semantics. The v2.6.0 entry is a feature/fix, meaning the contract shifted. Before shipping, determine whether your closure runs before or after the model save, what arguments it receives, and what happens to its return value. A callback that saves the model and a package that also saves it can produce double-write or stale-model bugs.
• Silent callback failures. Closures that throw inside a Nova API request can surface as a generic 500 or, worse, a swallowed failure where the inline value appears saved but the callback didn't run. Wrap side effects in try/catch with Log::warning during rollout, then tighten.
• Nova version drift. Verify compatibility against your installed laravel/nova before installing; the package's JS assets are built against a specific major and the front-end build changes between them.
• Authorization gaps. Manually test with a read-only Nova user against the index endpoint. Policies are enforced server-side on detail updates; index-level mutation routes are where authors forget Gate::check.
• Debugging. Open devtools Network and watch the inline save payload. Compare its shape with a normal PUT /nova-api/{resource}/{id}. Mismatches point at Nova-version incompatibility; a correct payload with no effect points at the callback or a missing save.
• Extension points. With the callback hook available you can often avoid forking: do derived work in the closure rather than patching the package. Fork only if you're prepared to maintain it.
• Escape hatch. Wrap the field in a feature flag (config('live-update.enabled') or a canSee closure) so you can disable inline editing per-resource without a deploy — especially important while you're validating the new callback behaviour in production.