Nova Order Field Laravel Package

Product Decisions This Supports

• Answers "who controls display order, and at what friction?" — a question that quietly gates a lot of admin-facing roadmap items. Drag-and-drop reordering converts a brittle "sort weight" integer field into a tactile editor action that persists automatically. It applies to navigation menus, hero sliders, FAQ lists, blog categories, product collections, and galleries. The decision it unblocks is whether manual ordering is a feature worth shipping at all — and if it is, this lets you ship it cheaply instead of deferring it indefinitely.
• Prices an admin UX improvement in units comparable to customer-facing work. Adoption costs roughly 1–3 developer days less than hand-rolling a Nova field, with no licence fee and no vendor contract. That makes "make the admin pleasant to use" a line item you can weigh against customer-facing work in prioritisation, rather than an unfunded nice-to-have that never clears the bar.
• Reframes build vs. buy as build vs. adopt vs. defer. Adopting is the cheap third path between a custom Nova field and the spreadsheet-and-email workflow that teams default to when nothing gets prioritised. Treat it as a time-boxed adoption decision: integrate, validate in a spike, then decide whether to own a fork.
• Feeds the platform question: stay on Nova vs. migrate to Filament or a custom admin. The package hard-locks to Laravel Nova, so it is a small sunk-cost signal in that debate. Let it be one input to that conversation — never the deciding one, and never a reason to stay on Nova by itself.
• A roadmap risk-register entry you should record now, not discover later. Last release January 2022, 59 stars, zero listed dependents, single maintainer. It belongs in the "small OSS dependency, unowned" bucket. The decision is tolerate and monitor with a named owner — not invest, not ignore.
• Scoping guardrails you should state out loud before promising anything. It does not support nested or hierarchical ordering (trees, multi-level menus), nor per-context ordering (locale, store, category) beyond what your model and trait configuration already express. Do not let "we have drag-and-drop" become "we can do nested menus" in a stakeholder's head.
• Internal-only scope, priced purely in developer time. No customer-facing surface, no pricing implications, no analytics instrumentation. Keep it out of the customer roadmap and out of any customer-facing commitment.

When to Consider This Package

Consider it when:

• You are already running Laravel Nova in production. Outside Nova the package is inert and must not influence an admin-panel choice.
• You need simple, single-column drag-and-drop reordering that writes to an order-style integer column on an Eloquent model.
• Editors are the primary users and reordering is frequent enough that manual numeric entry is a genuine pain point.
• Your team can absorb a small, stale dependency: the field is narrow, MIT-licensed, and its failure mode is admin UI breakage on a Nova upgrade rather than data loss.
• You are running a spike or MVP where speed beats long-term ownership, and you are comfortable treating a fork as a pre-approved fallback.
• You can meet the prerequisites: a backfilled, normalised sequence (clean 1..n, no duplicates or nulls), a normal index on the order column, no unique constraint (drag flows commonly write temporary duplicates), the index's default sort aligned to the order column, and Nova's standard authorization so reorder requests respect the resource's update policy and tenant scoping.

Look elsewhere when:

• You need hierarchical or nested ordering — this is a flat-list field.
• You need multi-context scoping (per-locale, per-store, per-category) beyond what your model configuration already expresses.
• Maintenance guarantees matter. A 2022 release against a moving Nova major-version cadence reopens the compatibility question at every upgrade. Prefer an actively maintained field, or budget explicitly to vendor and fork.
• You are on Filament, Voyager, or a custom admin — the Nova field API does not transfer; use the framework's native reorderable-table support.
• You want an all-in-one solution covering ordering plus publishing, versioning, or scheduling. This is deliberately single-purpose.
• You cannot accept Nova's commercial licensing across CI, staging, and contractor machines. That is frequently the real blocker, not this package.
• The ordering is high-volume, transactional, or customer-facing. Keep those business rules in application-owned services, not in an admin field.

Evaluate in the same breath: a hand-written Nova field (a few hundred lines, full ownership), a general-purpose model-sorting package paired with a minimal custom field, or Nova's own newer table-ordering capabilities if your version provides them.

How to Pitch It (Stakeholders)

Executive summary. michielkempen/nova-order-field is a small, MIT-licensed add-on for the Laravel Nova admin panel that gives editors drag-and-drop control over the order records appear in — menus, sliders, categories, FAQs. It replaces an error-prone manual "sort weight" field with a tactile interface, costing roughly 1–3 developer days less than building the equivalent ourselves and carrying no licence fee. The trade-offs are honest and bounded: it only works inside Nova (which we already license), it has a single maintainer and a last release of January 2022, and its community footprint is minimal (59 stars, no listed dependents). The recommendation is adopt as a low-risk convenience with a documented exit: integrate through normal dependency review, verify against our current Nova version in a one-day spike, and treat a fork or replacement as a pre-approved fallback if it breaks during an upgrade.

For engineering. It is a Nova field plus the conventional sortable-model trait — modest surface area, easy to read, easy to fork. Ask for: a compatibility check against our exact Nova/Laravel/PHP matrix; a smoke test of reorder persistence, including under pagination and filters; confirmation that the reorder endpoint sits behind Nova middleware and enforces the resource's update policy and tenant scoping; and confirmation that a broken upgrade path is a UI regression, not a data-integrity one. Pilot on one non-critical resource first, pin the Composer version, mount the field onlyOnIndex() so editors cannot hand-edit raw order values, and backfill to a clean sequence before rollout. Flag it in the dependency inventory as unmaintained-but-tolerated with a named owner and a slot on the Nova upgrade checklist.

For design/product. This is a scoping enabler: it lets us say yes to "let editors reorder these" without spending a sprint. It is flat-list only — no nested hierarchies, no per-context ordering — and it is an internal admin tool, so it does not move customer-facing metrics on its own. Treat it as a deliberate small bet with a cheap exit, not a platform commitment, and do not let it become the argument for or against staying on Nova.