Filament Sidebar Editor Laravel Package

Product Decisions This Supports

• Build vs. buy for admin navigation personalization. This package replaces a deceptively expensive in-house feature — drag-and-drop reordering, hide/show, per-scope persistence, live preview, reset/discard semantics, and pinned-item safety rules — that teams typically underestimate by 4–8 weeks of engineering plus ongoing maintenance. At v0.1.0 it is a candidate to evaluate against a build, not a settled answer.
• Information architecture: hardcoded vs. user-curated navigation. Today most Filament panels ship one fixed nav that the product team owns. This package shifts that decision: navigation becomes a preference users (or tenants) own. That is a roadmap-level choice about who is responsible for a cluttered admin panel.
• Multi-tenant product strategy. storeOnTenant() vs. storePerUser() vs. storeGlobally() is not a technical toggle — it encodes a product decision about whether layout is an org-level configuration (set by an admin, shared by a team) or an individual preference. Pick this deliberately; migrating scope later means data migration.
• Which segments get personalization. Per-user storage supports power users and large panels; global-per-panel storage supports a single curated "house" navigation. This lets you ship different UX to different plans without forking the codebase.
• Localization and market expansion. English, French and Arabic with RTL and dark-mode support means this feature is usable in MENA/FR markets without a follow-up project — relevant if those are target regions.
• Adoption risk / roadmap gating. v0.1.0 with no prior history means the API surface (plugin registration, storage drivers, authorize(), pinnedItems(), fixedMainGroup()) can move. That constrains it to internal admin tooling or time-boxed experiments until it reaches a stable 1.x — a decision the PM should make explicitly rather than let a developer make by installing it.
• Safety and lockout policy. "The editor page is always pinned" and "a group holding a pinned page cannot be hidden" is a product rule baked into the package. If your product needs different guardrails (e.g., compliance-required pages that must never be hidden), verify pinnedItems()/fixedMainGroup() cover it before committing.

When to Consider This Package

Consider it when:

• You run one or more Filament panels with a large or growing navigation (roughly 15+ items, or multiple nav groups), where users demonstrably struggle to find things or where different roles need different slices of the admin.
• You are multi-tenant and want tenant admins, not your engineers, to curate navigation for their teams.
• You want composable navigation rather than a fork — it wraps whatever NavigationManager is bound via extend(), so it can coexist with other navigation-altering packages. Confirm the composition actually holds with your other nav plugins.
• You need RTL / Arabic / French or theming flexibility out of the box; rebuilding that in-house is a real cost.
• You can accept pre-1.0 churn — i.e., internal admin tooling, an internal-only rollout, or a spike with a pinned version and a fallback plan.
• You want test evidence before adopting: the Testbench workbench and Playwright e2e suite (hide, drag-and-drop, save, reset, RTL) in CI is a meaningful signal for a 0.1.0 and lowers the cost of your own evaluation.

Look elsewhere or defer when:

• Your panel is small and stable — the maintenance and upgrade surface outweighs the benefit of a handful of reorderable links.
• You are not on Filament, or you need navigation outside a panel context.
• You require role/permission-level layout governance beyond a single authorize() gate — e.g., per-role default layouts, approval workflows for shared layouts, audit trails of who changed what. The package offers storage scopes, not a governance model.
• You need long-term API stability guarantees, a support contract, or an SLA. v0.1.0 with no prior release history is the opposite of that.
• Your persistence model doesn't fit the four drivers and you don't want to own a custom storeUsing() implementation.
• You have regulatory or accessibility requirements the package hasn't been validated against (drag-and-drop keyboard accessibility is the usual gap; the release notes don't claim it, so test it).

How to Pitch It (Stakeholders)

For executives (30 seconds): This is a small, focused add-on for our admin panel that lets each user or tenant arrange their own navigation — hide what they don't use, reorder what they do, with a live preview and a reset. The alternative is building it ourselves: several weeks of engineering plus permanent upkeep for a feature users notice only when it's missing. It supports English, French and Arabic (including right-to-left), ships with an automated test suite, and plugs into our existing panel rather than replacing it. The caveat is maturity: it's a first release at v0.1.0, so I'd recommend a time-boxed pilot in an internal or single-tenant admin first, pinned to a version, with a fallback to a plain fixed navigation if it doesn't hold up. Cost of trying is low; cost of building is not.

For engineering: It registers per panel via SidebarEditorPlugin::make(); panels without it are untouched, so rollout is incremental and reversible. Storage is a deliberate choice — tenant column, per-user, one layout per panel (default), or custom via store()/storeUsing() — so treat that as a data-model decision, not a config flag. It wraps the bound NavigationManager through extend(), so verify composition with any other navigation packages before committing. New pages and resources appear automatically and removed ones drop out, which removes the stale-layout failure mode we'd otherwise have to build. Guardrails are built in (editor page always pinned; pinned groups can't be hidden) and extensible via pinnedItems()/fixedMainGroup(). Before pilot: confirm Filament version compatibility, validate keyboard accessibility of drag-and-drop, and pin the dependency — expect breaking changes before 1.0. Existing Testbench workbench and Playwright e2e coverage means our evaluation can focus on fit rather than on re-proving the basics.