Product Decisions This Supports
- Admin UX backlog prioritization: the package's only real job — letting an admin drag-and-drop rows in a nested tree listing (categories, menus, pages, org units) and persisting the new order — is a recurring roadmap item in almost every CMS or catalog product. Use it as a signal that "manual ordering of hierarchical content" is a known, recurring need worth a ticket, not a library decision.
- Build vs. buy (verdict: build): with 2 stars, 0 dependents, an archived repo, and a last release in August 2016, the "buy" side of this equation is effectively empty. The realistic decision is build a small reorder endpoint + drag-and-drop UI, budgeted at days, not a procurement or integration project.
- Framework-fit check on the roadmap: this is a Symfony 2/3 bundle, not a Laravel package. If your roadmap assumes Laravel, any adoption cost includes a port — that reframes it from "dependency" to "reference implementation," which changes the approval path entirely.
- Reference design for the reorder contract: the genuinely reusable artifact is the pattern — a tree listing plus a persisted sort operation. That informs API shape (a
PATCH /tree/reorder with parent + position), validation rules, and concurrency handling, independent of the code itself.
- Not a platform/architecture decision: nothing here justifies a dependency, a service contract, or an ADR. It is at most an input to a feature spec.
When to Consider This Package
Consider it only when all of the following are true:
- You are maintaining a legacy Symfony 2.x/3.x application (roughly PHP 5.5–7.x era) where this bundle is already installed, and you are weighing whether to keep or remove it.
- You need tree reordering in an admin listing and have no budget to replace it this quarter.
- You have accepted that the code is unmaintained, will receive no security patches, and must be vendored or forked for any PHP/framework upgrade.
Look elsewhere — or build — when:
- Your stack is Laravel (the premise of this evaluation). There is no compatible artifact here; you would be porting abandoned 2016-era Symfony code, which is strictly more work than writing the feature.
- You need anything modern: PHP 8.x, Symfony 5+/Laravel 9+, Livewire/Inertia/Alpine front ends, or an actively patched dependency.
- You require support, CVE response, or a maintainer to escalate to. Archived: yes, dependents: 0 — there is no one on the other end.
- Your tree is large or write-heavy: nested-set reordering has real correctness and locking considerations that an unmaintained 2016 bundle will not help you reason about.
The low opportunity score (19.6) is consistent with this: the problem is real and common, the package is not the answer.
How to Pitch It (Stakeholders)
For executives: This is a small, abandoned Symfony plugin last released in 2016, with essentially no adoption and no maintainer. It is not a Laravel package and cannot be dropped into our stack. I do not recommend adopting it. The underlying need — letting admins reorder nested content in the admin panel — is legitimate and worth scheduling, but the right move is a small in-house implementation estimated in days, using maintained, well-supported tooling we already run. Recommendation: close as "do not adopt," keep the requirement on the roadmap.
For engineering: Treat this as a design reference, not a dependency. It confirms a common pattern — server-side persisted sort order over a nested listing — with zero transferable code for our stack. Proposed alternative: a reorder endpoint that accepts id, parent_id, and position, validates against the tree, applies the move transactionally, and returns the affected subtree; front end via the maintained drag-and-drop library of our choice. That is smaller than the cost of porting and auditing 2016 Symfony code, and it leaves us with something we can patch.