Sortable Behavior Bundle Laravel Package

Product Decisions This Supports

• Admin content-ordering UX (build vs. buy): If the product roadmap includes editorial control over ordered content — navigation menus, homepage banners, FAQ ordering, curated product lists, gallery sequences — this package supplies the drag-and-drop reordering mechanic and the persistence convention behind it, instead of a sprint of custom admin work.
• Prioritization of admin tooling on the roadmap: Ordering is usually a "table stakes" feature that never earns a roadmap slot on its own. Adopting a small MIT-licensed bundle lets you deliver it as an implementation detail and spend the roadmap on differentiators.
• Feature feasibility for curated/merchandised experiences: Confirms that "editors can reorder X without engineering" is achievable cheaply, which is often the gating question for merchandising, CMS, and marketing-driven roadmap items.
• Buy/borrow vs. build for a narrow, non-differentiating capability: Drag-and-drop ordering with a persisted sort ordinal is solved, well-understood, and has no competitive value. This is a textbook "borrow" decision — the real cost is integration, not invention.
• Technical debt and platform-risk decisions: An 11-star, 0-dependent, single-vendor, READ-ONLY mirror is a vendoring decision, not a dependency decision. That reframes build-vs-buy toward "buy the code once, own it thereafter," with an explicit internal maintenance owner on the roadmap.
• Framework-consolidation decisions: This package is Symfony + Sonata Admin, not Laravel. If the roadmap contains a framework consolidation to Laravel, this capability is not portable and the ordering feature becomes a re-build item — the exact kind of hidden cost that should surface at planning time, not at migration time.

When to Consider This Package

Consider it only when all of the following hold:

• The stack is Symfony with Sonata Admin for back-office. This is a hard gate — the package is a Symfony bundle and offers nothing to a Laravel codebase.
• Entities are Doctrine-mapped and need a persisted manual ordering (a sort/position column) rendered as a sortable admin list.
• Ordering is an internal, low-blast-radius capability where a bug means "editor has to drag again," not "checkout fails." The risk profile does not justify a hardened commercial component.
• Your team is comfortable vendoring or forking the source into your own repository and owning it, rather than depending on upstream releases. With 11 stars, zero dependents, and a read-only mirror, treat upstream as a snapshot, not a supply chain.
• You have a named internal owner for the forked code and a documented upgrade path for the Symfony/Sonata versions you run.
• MIT licensing is acceptable for your distribution and legal posture (it is, for most products).

Look elsewhere — or build the ~small amount of code yourself — when any of these are true:

• You are on Laravel. No amount of adaptation makes this the right choice; the correct comparison is a Laravel-native ordering implementation.
• You are not on Sonata Admin, or you are migrating off it. Coupling your admin ordering UX to a bundle that assumes Sonata creates a migration liability.
• You need ordering at a scale or complexity beyond a single integer column: per-locale ordering, per-tenant ordering, ordering across nested/scoped collections, or concurrent-editor conflict resolution.
• You require vendor support, SLAs, security patching commitments, or a community large enough to surface and fix issues. Zero dependents and a single maintainer mean you are the maintainers.
• Your procurement or security process requires provenance signals (release cadence, CVE history, multi-maintainer governance) that a project this size cannot supply.
• The feature is customer-facing and load-bearing — for example, ordering drives pricing tiers or eligibility rules — where correctness deserves first-class ownership rather than a borrowed dependency.

How to Pitch It (Stakeholders)

For executives — one paragraph: This is a small, free, MIT-licensed component that gives content editors drag-and-drop control over the order of items in the admin panel — menus, banners, lists. It removes a recurring "can marketing reorder this without a ticket?" request from the backlog at effectively zero license cost. The caveat is that it is a very small open-source project (11 stars, no downstream users, one maintainer, read-only mirror), so we should not treat it as a supported vendor dependency. The recommendation is to copy the source into our codebase and own it — a one-time integration cost plus a small, ongoing maintenance line item, in exchange for a capability we would otherwise build ourselves.

For engineering — the summary: Symfony bundle for Sonata Admin that provides sortable list behavior backed by a persisted sort ordinal on Doctrine entities. It solves a narrow, well-understood problem and is small enough to audit in an afternoon. Because upstream is a read-only mirror with a single maintainer and no dependents, we adopt it as a vendored fork under our own namespace, with our own tests around the ordering invariants (uniqueness, gap handling, reorder-under-concurrency). Integration risk is version coupling to Sonata Admin; pin your Symfony and Sonata versions and verify compatibility before committing. Note: this is not usable from Laravel — if any part of the roadmap assumes a PHP-framework-agnostic component, that assumption is wrong and should be corrected now.

Decision requested: Approve borrowing the code as a vendored fork for the Symfony/Sonata admin, with a named owner and a backlog item for hardening; reject treating it as an external dependency with an implied support contract.