Sortable Behavior Bundle Laravel Package

Technical Evaluation

Headline risk: this is not a Laravel package. The name and repo (pixSortableBehaviorBundle) identify it as a Symfony bundle, not a Composer library with Laravel support. It is designed to plug into the Symfony kernel as a bundle, register services through a DI Extension class, and integrate with Sonata Admin and Doctrine (via the Gedmo/Stof Sortable extension) to render up/down/move-to-top controls and persist an integer position column. None of that lifecycle exists in Laravel (Eloquent models, service providers, no bundle/compiler-pass model, no Sonata Admin).

Architecture fit

• Laravel/Eloquent stack: no fit. Not installable in a meaningful way; there is no service provider, no facade, no Eloquent trait, no Blade/Inertia UI. Adopting it would mean adopting Symfony + Doctrine + Sonata for the admin surface.
• Symfony + Sonata Admin + Doctrine stack: plausible, but dated. Value is real (drag/drop reordering is a common admin requirement) but the implementation assumes Symfony 4/5-era wiring and Gedmo Sortable semantics.
• Any other PHP framework or headless API: no fit; the package is UI-and-admin-coupled, not a domain service.

Integration feasibility

• Estimated effort for a Laravel target: not an integration, a rewrite. Roughly the same cost as building a position-based reorder capability yourself (small), with none of the package's code reusable.
• Effort for a legacy Symfony/Sonata target: low-to-moderate, gated entirely on version compatibility (see below).

Technical risk — high

• Provenance: 0 stars, 0 dependents, 0 dependents of dependents. This is a fork/re-host of the well-known Pix pixSortableBehaviorBundle; the canonical upstream exists and is more used. The copy under Software-For-Asset-Management has no visible community, no issue triage, no CI signals in the metadata provided.
• Abandonment: last release 2020-10-16. That predates PHP 8.1/8.2/8.3, Doctrine 3, and Sonata Admin 5. Expect Composer constraint conflicts immediately.
• Security/supply chain: single-maintainer, unmaintained code executing inside an admin panel (authenticated, high-privilege surface). No security policy, no CVE feed, no patching commitment.
• The score of 0 is consistent with the evidence; treat this as "read the source for ideas," not "take a dependency."

Key questions

1. What is the actual target stack — Laravel/Eloquent, or a Symfony/Sonata admin that we're loosely calling "PHP"?
2. If Laravel: what's driving this candidate? Reordering UI, or an existing data model with a position column already in place?
3. If Symfony: which versions of Symfony, Sonata Admin, Doctrine ORM, and stof/doctrine-extensions-bundle are pinned, and does the bundle's composer.json allow them?
4. Is the requirement simple manual reordering (up/down/top), or true drag-and-drop with reordering within filtered/paginated subsets?
5. Who owns the fork if we take it — do we have a maintainer willing to own patches permanently?

Integration Approach

Stack fit

• Laravel (most likely intent): reject. Recommend spatie/eloquent-sortable (actively maintained, Eloquent-native, trait-based, handles scoped sorting groups) or a ~150-line in-house trait.
• Symfony + Sonata: consider the canonical upstream Pix bundle first, then this fork only if it contains a specific patch you need. Either way, plan to fork and vendor.

Migration path (Laravel)

1. Add an integer position column (nullable, indexed) with a composite index on the scope columns (position, plus any parent/group key such as category_id or tenant_id).
2. Encapsulate reordering behind a single service/interface — moveTo(int $id, int $position) and moveBefore/moveAfter — so the storage strategy is swappable.
3. Implement with a transaction + SELECT ... FOR UPDATE on the affected scope, then renumber the affected window.
4. Expose one endpoint (PATCH /resource/{id}/position) plus a UI that sends {id, newIndex}; debounce drag events.
5. Do not port the bundle's Sonata controller/UI code.

Consider fractional/lexicographic ranking (position as a decimal or sortable string) as an alternative: single-row writes instead of O(n) renumbering, at the cost of rebalancing jobs.

Compatibility

• Verify composer.json: PHP constraint, symfony/* constraints, Doctrine ORM version, Sonata Admin version, and whether it requires gedmo/doctrine-extensions directly or through stof/doctrine-extensions-bundle.
• Expect to pin symfony/* to older minors or to patch constraints to run on PHP 8.2+. Do not assume --ignore-platform-reqs is acceptable in production.
• Gedmo Sortable changes position semantics across majors; behavior drift is a real risk during any Doctrine upgrade.

Sequencing

1. Spike (≤2 days): confirm the stack question, and in parallel prototype the reorder endpoint + UI against the real data volume.
2. Decision gate: build-in-house vs. spatie vs. fork-the-Symfony-bundle. Default to build/spatie for Laravel.
3. Isolate: put reordering behind one interface and one endpoint before any UI work.
4. Ship behind a flag, migrate existing rows to a normalized position in a backfill job, then enable.
5. Only if Symfony: vendor the fork, pin versions, and add it to the owned-fork list with a named maintainer.

Operational Impact

Maintenance

• Effectively self-maintained. No upstream commits since 2020; you inherit every future PHP/Doctrine/Symfony break. Budget a recurring cost (est. a few engineer-days per major framework upgrade) for a feature that is, in isolation, small.
• For Laravel, spatie/eloquent-sortable shifts that burden to a maintained vendor — the correct trade.

Support

• No community, no issue triage, no documented support channel. Internal ownership is mandatory: named maintainer, fork pinned in composer.json by VCS path, and a SECURITY.md-style expectation of prompt patching for admin-surface code.
• Documentation is minimal; onboarding relies on reading the source.

Scaling

• Position-based reordering is write-amplifying: moving one item to the top rewrites every row in the scope (O(n) UPDATEs). Fine to a few thousand rows per scope; problematic for large or hot scopes.
• Watch for SELECT-then-UPDATE loops causing N+1 queries and long transactions; a single drag on a 5k-row list can hold locks long enough to cause visible latency.
• Scope the sort key (per category/tenant) to keep the rewritten window small; consider fractional ranking if scopes are large or reorder frequency is high.
• Admin-panel traffic is usually low-QPS, so the dominant scaling concern is lock duration and table bloat, not throughput.

Failure modes

• Concurrent reorders producing duplicate or skipped positions (no unique constraint, no locking) — the classic bug in this pattern. Mitigate with a transaction + row locks and a periodic dedupe/reindex job.
• Gaps and negative/drifting positions after deletes or failed partial updates; sort order silently becomes non-deterministic. Always order by (position, id) as a tiebreaker.
• Renumbering storms under bulk imports or CSV loads that bypass the reorder service.
• Breakage on framework upgrade — the most likely failure mode for this specific package, and it fails at boot (bundle registration / DI compile), i.e., full admin outage rather than a degraded feature.
• Abandoned-dependency exposure in an authenticated admin surface; no patch path if a vulnerability is found.

Ramp-up

• Conceptually trivial: a position integer plus move operations every engineer already understands — low cognitive load, no training needed.
• The non-obvious part is the operational discipline: locking, scoping, backfill, and reindex jobs. Document those or the feature regresses within two quarters.
• For the Symfony path specifically, ramp-up includes Gedmo Sortable's semantics (it manages the position field itself and can conflict with manual writes) — budget a day of source reading before anyone debugs a "sorting is wrong" ticket.

Recommendation: do not adopt as a dependency. For a Laravel target, use spatie/eloquent-sortable or a small in-house trait behind a single reorder interface; for a Symfony/Sonata target, evaluate the canonical upstream Pix bundle and vendor it with a named owner.