Admin Tree Bundle Laravel Package

Product Decisions This Supports

• Feature scoping for admin-side ordering UX. The package adds "move up / move down" controls to CRUD list views for tree-structured records. That is a narrow, well-understood affordance: it lets an admin change sibling display order (category rails, menu items, taxonomy lists) without editing a numeric position field by hand.
• Build vs. buy for micro-features. This is the kind of capability that should be sized honestly before it enters a roadmap. It is roughly a position column, a swap operation, and two buttons in a list view — a day of work in your own admin stack. The package does not change that calculus; it only offers a pre-built version for one specific framework.
• Ecosystem fit as a first-class decision criterion. Despite being catalogued here as a "Laravel/PHP package," fsi/admin-tree-bundle is a Symfony bundle built for the FSi AdminBundle suite (fsi/admin-bundle). It has no Laravel service provider, no Blade views, and no Eloquent integration. For a Laravel product, this is not a viable dependency — the decision it actually informs is "do we support a Symfony-based admin, or not?"
• Risk budgeting for admin tooling. Admin panels are low-glamour, high-blast-radius surfaces. Deciding whether ordering behavior lives in a vendored third-party bundle versus your own code is a maintainability decision, not just a feature decision.
• Use cases it would serve, if the stack matched: catalog category ordering, CMS navigation menus, sitemap/taxonomy display order, org-chart sibling ordering — all "sort within a level," not "restructure the hierarchy."

When to Consider This Package

Consider it only if all of the following are true:

• You are running Symfony with fsi/admin-bundle already installed, on a compatible version line.
• You specifically need up/down sibling reordering in admin list views and nothing more.
• You accept that you will own the code: last release was 2020-02-17, stars are 0, dependents are 0, and there is no visible community or security-patch path. Forking it into your repo is the realistic adoption model.

Look elsewhere if:

• You are on Laravel. This is the disqualifying case. There is no bridge; installing it means pulling Symfony framework bundles into a Laravel app for two buttons. Use your admin framework's native tools instead — Filament ordering/nested-set plugins, Nova's sortable fields, Backpack's reorder operation, or kalnoy/nestedset at the model layer plus a small Blade component.
• You need drag-and-drop. Up/down buttons are a weaker interaction than drag-and-drop once lists exceed ~15 items; a lightweight SortableJS integration is a better investment.
• You need real hierarchy editing (reparenting, moving subtrees), not just sibling order. This package does not do that.
• You need a maintained dependency. Zero stars, zero dependents, and four-plus years without a release are objective abandonment signals. Adopting it makes your team the sole maintainer of a component you did not write.
• Your admin is not FSi AdminBundle. The value is entirely in the integration; stripped of it, the remaining logic is trivial.

How to Pitch It (Stakeholders)

Recommendation: do not adopt. Build the small piece ourselves when the need is real.

For executives: The capability on offer — reordering items in an admin list — is genuinely small, and the package that provides it is unmaintained (no release since early 2020, no adoption, no community). It is also built for Symfony, not our Laravel stack. There is no cost saving here worth the ongoing risk of owning an orphaned dependency in an admin surface. Our exposure is a day or two of engineering, done once, tested, and fully ours.

For engineering: Treat this as a rejected dependency with a trivial reimplementation path. The feature is a position column with a transactional swap and two list-view buttons; if we need nested semantics, we use kalnoy/nestedset (Laravel) or the ordering primitives already present in our admin framework. Revisit the "buy" option only in the scenario where the organization standardizes on Symfony + FSi AdminBundle — in which case the whole admin stack decision, not this bundle, is the thing on the table.