Admin Positionable Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for the admin panel. This is a "buy" candidate for a single, narrow CRUD affordance: up/down arrow buttons that increment or decrement an integer position column on list rows. It informs the decision of whether ordered-list editing is worth building in-house versus wiring in an existing bundle.
• Roadmap scoping for ordering-dependent features. Any surface with user-controlled sequence — navigation menus, FAQ entries, homepage slides, product galleries, category ordering, testimonials, form field order — needs a "position" concept. This package is a reference implementation of the pattern, and reading its scope is faster than spec'ing the feature from scratch.
• Data-model decisions up front. Adoption forces the entity to carry a position integer plus a PositionableInterface and a Doctrine listener. That's a schema decision that's cheap at design time and expensive after launch, so evaluating this package is really a prompt to decide now whether ordered content is on the roadmap.
• Prioritization signal. An opportunity score of 4.15 against 1 star and 0 dependents is a useful contradiction: it says the capability is genuinely valuable to admin users, while this implementation has no adoption evidence. It supports the conclusion "the need is real, this artifact is not the answer."
• Stack-fit triage. The decisive PM-level finding: this is a Symfony bundle (FSi AdminBundle ecosystem), not a Laravel package, and its last release was August 2019. For a Laravel shop this closes the evaluation immediately and moves the item to the build column.

When to Consider This Package

Consider it only when all of the following hold:

• You are already running FSi AdminBundle on a Symfony 3.x/4.x codebase with PHP 7.x, and the admin lists are generated by that bundle's CRUD/data-grid machinery. Outside that host, it does nothing.
• You need the minimal interaction (discrete up/down moves), not drag-and-drop, multi-select bulk reordering, or reordering across filtered/paginated views.
• Ordering is global per entity, not scoped per locale, tenant, parent category, or user.
• You accept that you are adopting unmaintained code — plan to vendor/fork it, pin it, and own the Doctrine listener yourself. MIT license makes that legally trivial.

Look elsewhere — or build — when:

• Your stack is Laravel. This is a hard incompatibility, not a porting inconvenience. Equivalent 20-line implementations (or spatie/eloquent-sortable) exist for Eloquent.
• You're on Symfony 5.4+ or 6/7. Seven-year-old bundles in this family will drag in abandoned transitive dependencies; the integration cost exceeds the feature cost.
• You need tree/nested ordering. This handles flat sibling lists only; nested sets or parent-scoped positioning is a different problem.
• You need drag-and-drop or concurrent-edit safety. Position swaps need transactional guards and conflict handling; this gives you neither.
• Reordering is a core, high-traffic workflow. Then it deserves a first-class endpoint, optimistic UI, and audit history — not a dead dependency.

How to Pitch It (Stakeholders)

To executives (one paragraph): We evaluated an open-source component for "move item up/down" in our admin lists. The underlying user need is real and recurring across content surfaces, but the component itself is a Symfony-only bundle last released in 2019 with no downstream users — effectively abandoned. The feature it provides is small and well understood, so the recommended path is to implement it in-house on our own stack rather than inherit a dead dependency. Cost is measured in hours, not weeks; risk of adopting the package is ongoing maintenance of code nobody else uses.

To engineering (one paragraph): fsi/admin-positionable-bundle adds increment/decrement controls to FSi AdminBundle data grids, backed by a position integer, a PositionableInterface, and a Doctrine listener. It's MIT, Symfony 3/4-era, unmaintained since 2019, and incompatible with a Laravel codebase. Recommendation: do not adopt. Treat it as a design reference. Build a single reorder endpoint (PATCH /resource/{id}/position with an explicit target index), wrap the swap in a transaction with a unique constraint or gap-based numbering on position, and — if drag-and-drop is in scope — drive it from the front end against that one endpoint. Budget roughly a day including tests, and add the position column now for any entity on the ordering roadmap so we don't need a follow-up migration.