Filament Bookmarks Menu Laravel Package

Getting Started

The v5.0.0 release is primarily a compatibility and correctness release: it adds Filament v5 / Laravel 12–13 support (fixing the Filament v4 install error, #2) and tightens visibility rules around private bookmark folders.

First steps:

1. Confirm your stack. v5.0.0 targets Filament v5 with Laravel 12/13. If you are still on Filament v3, stay on the v3 branch — do not pull v5.0.0.
2. Require the package and register the plugin in your panel provider (->plugins([...])), then publish and run migrations so ownership columns exist before creating folders.
3. Open the bookmarks page once. With no folder id it now redirects to the first folder visible to the current user, or the panel home if none exist — that redirect is the quickest signal your ownership data is wired up correctly.
4. First real use case: a user creates a private folder, bookmarks a resource page into it, and sees it in the sidebar only for themselves. If a second user can see that folder, your ownership column/backfill is wrong, not the plugin.

Where to look first: the published migration (ownership column and indexes), the plugin config (navigation group, sort, label), and the bookmark folder resource/page — that is where visibility, actions, and redirect behavior are enforced.

Implementation Patterns

Ownership as the source of truth. Private folders are now filtered by owner in the sidebar, the page, and the actions. Treat the ownership column as authoritative and backfill existing rows deliberately: null (or whatever the package uses for shared) means visible to everyone, a user id means private. Do the backfill in the same deploy as the migration, before users hit the page.

Scope in queries, not just UI. If you build any custom listing, report, export, or dashboard widget over bookmark folders, add the same owner constraint the plugin uses. The v5 fixes cover the plugin's own surfaces; they do not cover your custom queries.

Multi-panel and tenancy. Register the plugin per panel and decide whether folders are shared across panels or namespaced per panel. If you use Filament tenancy, add the tenant key alongside the owner column and put a unique index on (owner_id, tenant_id, name)-style combinations to avoid duplicate folders per tenant.

Programmatic bookmarks. Creating folders/links from seeders, onboarding flows, or "save this page" buttons is fine via the models — just always set the owner explicitly. A missing owner silently produces a shared folder, which is the most common way private data leaks in this pattern.

Actions and authorization. Keep policy/permission checks in your policies so the plugin's actions and your custom actions agree. v5 makes removing a link touch only folders the user can see — if any internal workflow depended on "remove everywhere" semantics, replace it with an explicit admin path.

Dynamic link targets. Store the panel-relative URL or route name rather than an absolute URL when you generate bookmarks in code; panel path changes otherwise leave dead links. Keep labels and icons as data, not markup.

Redirect reliance. The no-id redirect to first visible folder is convenient for navigation menu entries — point your "Bookmarks" nav item at the page without an id and let the plugin resolve the destination.

Upgrade validation. The new test suite is the fastest way to confirm behavior on your Filament version. Run it in your app's CI context (or mirror its cases) against your database driver before rollout.

Gotchas and Tips

• Version pinning is the whole story. The install error on Filament v4 is fixed, but v5.0.0 is not a drop-in for Filament v3 projects. Pin ^5.0 only where Filament v5 is present; keep v3 apps on the v3 branch and note it in your upgrade docs.
• Visibility is now enforced in three places. If you previously patched or forked any of the sidebar/page/action logic to hide folders, remove those patches — duplicated filtering tends to diverge and cause "visible in sidebar, 403 on page" bugs.
• Existing folders may become invisible. If your schema previously had no owner (or owner was always null), a strict private-folder rule can hide everything from non-owners. Verify with a real non-admin user after migrating, not just an admin.
• Tooltip escaping. Bookmark names are now escaped in the sidebar tooltip. If anyone stored HTML-ish strings in names expecting rendering, they will display literally — sanitize intentionally rather than reverting the escape.
• Redirect changes tests and deep links. Any test or onboarding flow asserting an empty bookmarks page at the bare URL will now fail or land on a folder. Update assertions to the first-visible-folder behavior.
• Partial removals. "Removing a link only touches folders the user can see" means a user can remove a link and still have it present in another user's folder. That is correct isolation, but support tickets will describe it as "the bookmark came back."
• Navigation caching. After changing permissions or ownership in production, clear cached views/navigation; stale sidebar state is easily mistaken for a visibility bug.
• Extend via config and policies first. Custom navigation labels, grouping, and sort belong in plugin config; access rules belong in policies. Forking the resource couples you to internals that just changed significantly between v4 and v5.
• Check rollback paths. Confirm the migration's down() and that ownership columns/indexes are dropped cleanly before deploying to production — this release adds schema you will want to reverse safely.