- How do I install and register the filament-sidebar-editor plugin in a Filament panel?
- Install it with composer require hoceineel/filament-sidebar-editor, then add SidebarEditorPlugin::make() to the plugins array of the Filament panel where you want sidebar editing. The plugin hooks the panel's navigation lifecycle by wrapping the bound NavigationManager via extend(), so it works as a per-panel opt-in. Register it on a non-production panel first to validate the editor UX before rolling it out.
- Which Filament versions does this sidebar editor support?
- The package documentation does not publish an explicit compatibility matrix, so check the composer.json constraints and the repository's CI matrix before installing. Because the plugin wraps Filament's internal NavigationManager, it is directly exposed to navigation API changes between Filament major versions. Pin a version and run your panel's test suite after any Filament upgrade.
- What is the difference between storeGlobally, storeOnTenant and storePerUser?
- The plugin ships with multiple storage drivers, including storeGlobally(), storeOnTenant() and storePerUser(), so you can decide whether a sidebar layout is shared across the whole panel, scoped to a tenant, or personal to each user. storeGlobally() is the zero-migration option and the fastest way to prove value. Tenant and per-user drivers add scoping but also pull in schema and deploy considerations.
- Do I need to run a migration to use this package?
- With storeGlobally() you can avoid a migration entirely, which makes it the easiest starting point. storeOnTenant() and storePerUser() almost certainly require a published migration or an added column, so plan for a deploy step and a backfill or seed decision. Confirm the exact schema in the package's migration stubs before shipping.
- How do I control who can access the Filament sidebar editor page?
- The editor is a configurable Filament page guarded by an authorize() gate, so you can decide which roles or panels can open it. For simple admin-only setups that gate is usually enough. If you need per-tenant or per-role editor access, verify whether the gate can be scoped without forking and add your own policy check where needed.
- Does hiding a navigation item prevent users from accessing the page?
- No. Hiding a navigation item is cosmetic only; it does not revoke access to the underlying page, resource or actions. Keep Filament's canAccess() checks, policies and middleware as the security boundary. Treat the sidebar editor as a UX tool, never as an authorization mechanism.
- How does drag and drop reordering work, and is there a live preview?
- The editor page lets users hide, show and drag-and-drop reorder navigation groups and pages, with save, reset and a live preview of the resulting sidebar. The repository includes a Playwright suite covering hide, drag-and-drop, save, reset and RTL behaviour, which is a meaningful signal at v0.1.0. Still exercise the flow in your own panel, especially with custom navigation items.
- What happens if a page is renamed, moved or deleted after a layout is saved?
- Deleted pages drop out of the saved layout automatically, but renamed or moved page classes can orphan stored layout entries because the identifier is likely class-based. There is no documented fallback for malformed layout data or layouts that reference only removed pages, so test whether navigation falls back to Filament's default or renders empty. Keep a reset path and a backup of stored layouts.
- Can I use this plugin for per-tenant sidebars in a multi-tenant SaaS panel?
- Yes, this is a strong fit for multi-tenant SaaS panels where each customer should see only the modules they bought. Use storeOnTenant() so layouts are scoped per tenant, and rely on the pinned-item or lockout protection so users cannot hide their own way back into the panel. Remember that hiding modules is not entitlement enforcement; keep policies and canAccess() as the real gate.
- Is version 0.1.0 stable enough for production, and is the package actively maintained?
- Treat v0.1.0 as pre-1.0: plugin builder methods such as storeOnTenant() and fixedMainGroup() can change without a deprecation cycle, so pin the exact version and review changelogs before upgrading. Maintenance risk is compounded if the package is maintained by a single author, so check recent commits and issue activity. It composes with other navigation-modifying packages through extend(), but wrap ordering with other extend() callers is not guaranteed, so test your full navigation stack.