Laravel Backpack Nestedmodels Laravel Package

Getting Started

This package replaces Backpack CRUD's default table view with a tree view for self-referencing (parent/child) Eloquent models. Start here if you have a model with a parent_id-style relationship and want visual hierarchy management.

Minimal steps:

1. composer require the package, then publish any config/views as instructed in its README (initial release, so expect a manual publish step).
2. Ensure your model has the standard Backpack CRUD setup (CrudTrait, a setup() method in its controller, etc.) and a parent/child relationship column Backpack can detect.
3. Point your CRUD controller at the tree view rather than the default table. Since tree and table routes cannot coexist yet, expect to swap the view on the controller that owns the tree.
4. First use case: open the CRUD list view and confirm nodes render as a tree, then drag to reorder roots or children and verify the parent/ordering columns were persisted.

Look first at the package's route definitions and the CRUD controller trait/method it exposes — that is where the tree/table switch lives, and it determines what you can and cannot customize.

Implementation Patterns

• Single-purpose controller: Because tree and table cannot live simultaneously (per the ToDos), dedicate one CRUD controller per tree-enabled model and keep it tree-only. If you need both, use separate controllers/routes for now.
• Structure editing in place: The tree view supports editing hierarchy directly — drag to reorder siblings and roots, and reparent nodes. Treat this as your primary admin workflow for nested content (categories, menus, departments, comment threads).
• Add child from node: The "add new children" action pre-fills the parent relationship. Wire your store() request handling so the parent key from the tree action is respected rather than overwritten by defaults.
• Preview before edit: The model preview is useful for read-only inspection in large trees. Use it as a quick sanity check rather than opening the edit form on every node.
• Deletion is recursive: Deleting a node removes all descendants. If you need softer behavior, override the destroy flow in your controller or add a confirmation/guard, since the built-in action is destructive by design.
• Reordering roots: Root-level reordering is supported, so you can maintain a deliberate top-level order (e.g. display order for a menu) without a separate sortable package.

Gotchas and Tips

• No lazy loading yet: The release explicitly lists AJAX loading, roots-only loading, and on-demand subtrees as ToDos. Every tree currently loads in full. On large datasets expect slow page loads — scope the query (limit depth, filter by tenant/status) in your controller, or avoid tree view for big tables until later versions.
• Route collisions: The ToDos mention needing special tree routes that don't interfere with table routes. Until that lands, do not assume tree and table views can serve the same URL. Mount the tree on its own CRUD controller/route.
• Recursive delete is irreversible: Confirm descendant deletion is acceptable for your data model, or add a confirmation dialog/policy check. Backups and soft deletes are strongly recommended before enabling the tree on production data.
• No modal editing yet: Editing opens the standard Backpack form (modal is a ToDo). Ensure your edit/update routes and fields are correct, since tree actions will redirect into them.
• Reordering persistence: Verify which column the package uses for ordering and parenting. If your model's ordering column differs from the expected convention, reordering may silently fail — check the generated request payload and the model's fillable/save path.
• Extension points: Since this is v1.0.0, expect views to be publishable and tweakable. Prefer overriding published views over editing vendor code so future releases don't break you — particularly relevant given the planned AJAX/modal work in upcoming versions.