Dcat Admin Sortable Laravel Package

Product Decisions This Supports

• An internal admin UX win, not a customer-facing feature. This package adds drag-and-drop row reordering to Dcat Admin grids — banners, categories, menus, FAQs, form fields, workflow stages — anything backed by an order/sort column. Admins stop hand-typing integers and stop filing "how do I move this to the top?" tickets. High perceived value, low effort, near-zero blast radius on customer-facing code.
• Roadmap sequencing and unblocking epics. Manual reordering is usually a buried prerequisite inside larger initiatives: CMS content ordering, navigation builders, product merchandising, workflow stage ordering. Adopting this cheaply unblocks those epics instead of letting "add manual sort" consume its own sprint slot. It's a strong filler-sprint candidate that demonstrates momentum on ops/admin friction without committing headline capacity.
• The central build-vs-buy call. The capability is genuinely small: a SortableJS binding, a sort column, an AJAX endpoint to persist positions. Buying costs a dependency with 5 stars, 0 dependents, and a single maintainer; building costs roughly 1–2 engineer-days plus tests. Treat it as "buy to prototype, build if it sticks" — adopt to validate that admins actually use manual ordering, then fork/vendor or reimplement once the UX is proven and the persistence semantics (concurrency, tie-breaking, audit) are understood.
• An ecosystem-scoped decision, not a general Laravel one. This only matters if we run Dcat Admin (Laravel admin panel, largely Chinese-language ecosystem). The real underlying question is a platform policy decision: do we allow community plugins in our admin panel, or keep the plugin surface minimal and own all admin code? Answering that once saves re-litigating it per plugin.
• Data-contract decisions it forces — which we should make regardless. Which column owns ordering, flat vs. nested, how concurrent edits resolve, whether ordering is auditable, and how ties break. These answers are valuable whether or not we keep the package, and they belong to us, not to the dependency.
• Prioritization signal. A low-cost, reversible, internal-tooling improvement with no data-model change beyond one indexed column. Good "filler" sprint work; bad headline initiative.

When to Consider This Package

Adopt when:

• We are already running Dcat Admin 2.x on a compatible Laravel/PHP version, and one or more grids need reordering.
• The requirement is flat, single-dimension, manual ordering — "put this banner third."
• We can pin an exact version, wrap calls behind an internal SortableGrid helper, and accept that we will likely fork it (acme/dcat-admin-sortable) rather than wait on upstream.
• The team is comfortable auditing a few hundred lines of third-party PHP/JS instead of relying on a maintainer.
• Scope is internal admin surfaces only — content and catalog tooling, not money-adjacent or high-traffic paths.
• We keep a manual fallback (editing the sort field in the form) so ordering never hard-depends on the JS asset.

Look elsewhere when:

• We are not on Dcat Admin. Filament, Nova, and Backpack have native or first-party reorderable-table support; a custom admin has no reason to import this.
• We need hierarchical/nested ordering (tree menus, multi-level categories) — use a nested-set package such as kalnoy/nestedset; flat sort columns degrade badly under nesting.
• We need concurrency safety, audit history, or scheduled ordering ("publish this order at 9am") — requirements this package almost certainly doesn't model.
• Ordering touches high-traffic or money-adjacent surfaces where a stale-position write or a broken AJAX endpoint causes real damage.
• Our dependency policy requires maintained packages with CI, security advisories, and a responsive maintainer. 5 stars / 0 dependents / single maintainer fails most such gates — plan for ownership transfer at adoption.
• We would be the first production dependent. Not disqualifying, but it means we are de facto QA and should budget accordingly.
• Documentation in the team's working language is a hard requirement — docs are thin and largely non-English.

Practical gate before committing: verify Laravel/PHP/Dcat constraints in composer.json against our version matrix; confirm the Composer package name actually maps to this repository (package name dcat-admin-sortable and repo name doct-admin-sortable diverge — a provenance red flag); confirm the reorder endpoint inherits Dcat auth middleware and per-resource policy (not a superuser bypass); confirm no mass assignment on the sort column; and confirm the license permits forking.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small, low-cost admin capability that lets content and catalog teams reorder items visually instead of editing numbers — a recurring source of support tickets and slow merchandising work. It touches only internal tooling, is fully reversible, and costs us a dependency rather than a build. The recommendation is a timeboxed pilot in one admin module; if usage justifies it, we fold the roughly 1–2 days of logic into our own codebase and drop the dependency. Downside is bounded: worst case we lose a day, and no customer-facing surface is affected. It also unblocks several roadmap epics that quietly depend on manual ordering (content ordering, navigation builders, merchandising) without consuming a dedicated sprint.

To engineering (the real pitch): It's a thin Dcat Admin extension — sortable grid rows plus a persistence endpoint — small enough to read in an afternoon and fork if the maintainer goes quiet (5 stars, 0 dependents, single maintainer: treat as unmaintained-by-default). Proposal: pin the exact version, fork into our namespace at adoption rather than after the first Dcat upgrade breaks it, wrap the calls behind an internal SortableGrid helper so we can swap implementations without touching call sites, and treat the sort column as our own contract — indexed unsignedInteger, NOT NULL DEFAULT 0, backfilled deterministically from a stable key, default scope orderBy('sort')->orderBy('id') for stable tie-breaking, plus an ordered() scope so no call site forgets. Add integration tests on the reorder endpoint covering ordering correctness, authorization/CSRF under a real admin session, pagination and filter scoping, NULL/duplicate keys, and concurrent writes. Keep a manual fallback (edit the sort field in the form) so ordering never hard-depends on the JS asset, and put a two-sprint review on the calendar: keep, fork, or replace. The main technical risk isn't complexity — it's the reorder write pattern (O(n) rewrites per drag, non-transactional, last-write-wins under concurrent admins) and Dcat upgrade breakage on grid-tool registration; both are cheap to contain if we own the code from day one.

Recommendation: Adopt conditionally — scoped to internal admin surfaces, forked and version-pinned from day one, behind a feature flag, starting with the single list where manual ordering has the clearest stakeholder ask. Do not let it become load-bearing infrastructure without first exercising the fork path.