Nova Inline Text Field Laravel Package

Getting Started

Confirm what the field actually does, first. The package description says inline-editable from the index; at least one internal note reads it as display-only. Those are different packages with different risk profiles (validation, authorization, audit trails). src/InlineText.php is tiny — read it end to end, drop one field on a scratch resource, and click it. Ten minutes gates everything below.

Prerequisites. Nova 4.x/5.x, Laravel 10/11, PHP 8.1+. You also need Nova's private Composer credentials configured locally and in CI before composer require will resolve — budget for that separately, it's usually the long pole.

Install, pinned.

composer require optimistdigital/nova-inline-text-field:^3.0.1

Never adopt 3.0.0. It ships an InlineText method signature incompatible with its parent Nova class, which in PHP is a fatal "Declaration of … must be compatible with …" error at class load — that takes down the whole Nova panel, not one field.

Verify the FQCN before writing field definitions. The vendor namespace (optimistdigital) and the GitHub org (outl1ne) have diverged, so grep src/ and composer.json rather than trusting the repo name. Then boot the panel once (/nova) on an empty resource before adding anything real — you want a fatal to surface in a clean place.

First use case: one low-traffic resource, one short single-value string — a display name, label, title, sort key.

use OptimistDigital\NovaInlineText\InlineText; // verify namespace in src/

public function fields(NovaRequest $request)
{
    return [
        InlineText::make('Display Name'),
    ];
}

Where to look first, in order: src/InlineText.php (parent class, overridden methods) → composer.json (Nova/PHP ranges, real namespace) → README → dist/ / resources/js/ (is the Vue side an input or a span? that answers the display-only question definitively).

Implementation Patterns

Wrap it, don't subclass it. The 3.0.1 fix exists because this class overrides Nova internals; a subclass inherits that fragility on every Nova minor. Return the configured field from a helper instead:

class InlineLabel
{
    public static function make(string $attribute, ?string $label = null): InlineText
    {
        return InlineText::make($attribute, $label ?? Str::headline($attribute))
            ->rules('required', 'string', 'max:255')
            ->onlyOnIndex();
    }
}

One place to swap the package out for a ~100-line custom field when it goes stale.

Placement. ->onlyOnIndex() for high-frequency edits; ->onlyOnDetail() where the value is informational; default (both) only for genuinely low-blast-radius attributes. If you plan to promise a sortable index column, check that sortable() is honored by the field class first.

Validate and authorize at the model/policy layer, not just the field. The two questions the pilot must answer: does the inline save enforce Nova rules and authorizedToUpdate, and does it fire Eloquent events? If either is "no," enforce it yourself — rules on the field and a policy-protected update endpoint, plus a saved observer so activity logs, search indexes, and audit tables don't drift silently.

Roll it out behind a flag. Ship the first field behind a config toggle or feature flag so you can disable one column without a revert, then measure (time-to-complete-edit, clicks per edit) before expanding to a second resource.

Pilot matrix — four paths on one resource: index render, successful save, validation failure, policy denial. Re-run all four after any Nova bump.

Testing. A request-level boot smoke test (authenticated GET /nova) catches class-load fatals that unit tests can't. Pair it with a feature test that POSTs the Nova update endpoint for the inline field, asserting the happy path and a 403 for a user without the policy.

Gotchas and Tips

3.0.0 in a composer.lock is a ship-today patch, not a next-sprint item — a routine deploy can kill the panel.

The private Nova repo is the real integration cost. The composer require is minutes; credential setup across local + CI plus smoke testing is closer to a day. Give the credentials an owner and an expiry plan, and check Nova auth first when a fresh CI runner fails mysteriously.

There's nothing to publish. No config, no migration, no vendor:publish. The field class is the config. Extension points: your helper (preferred), a thin wrapper Field subclass (cautious), or Nova Field macros for panel-wide conventions.

Version coupling is to a closed-source dependency with no changelog to diff your overrides against. Nova upgrades are a gated staging change with the smoke test, never a routine bump.

Blank field after an upgrade is usually assets, not PHP. Clear compiled views, re-run php artisan nova:publish, and check the browser console before touching the field definition.

Debugging a silently-failing save: php artisan route:list | grep nova to find the update endpoint, watch the network tab for the JSON response (Nova validation errors come back there), and confirm the field attribute name matches the model attribute exactly — a mismatch often "succeeds" with no visible change.

Keep it off derived state. Anything where an inline save should cascade — slugs, cached aggregates, denormalized columns, search indexes — is out of scope. The failure is silent and cumulative.

It's a Nova field, not a product surface. Don't push it into anything customer-facing.

Bus factor is real: 23 stars, 0 dependents, one small maintainer team, GitHub issues as the only support. Classify it as a convenience dependency; keep the wrapper thin, leave a fork-or-replace note in the repo, and treat "goes stale against a Nova major" as a when, not an if. The small surface area is what makes adoption — and the eventual fork — cheap, so don't let the field sprawl across twenty resources before the first one proves it paid off.