Filament Record Navigation Laravel Package

Getting Started

• Install with composer require josespinal/filament-record-navigation.
• Register the plugin in your panel provider (app/Providers/Filament/*PanelProvider.php) via ->plugin(FilamentRecordNavigationPlugin::make()).
• Look first at the package README for the exact trait/plugin registration for your Filament major version (v3 vs v4 APIs differ), then open the plugin class to see the config options for ordering, labels, and which pages get the navigation controls.
• First use case: open any EditRecord / ViewRecord page for a resource and verify the previous/next record controls appear in the header; click through a few records to confirm the buttons navigate and that header actions still work.

Implementation Patterns

• Per-panel opt-in. Register the plugin only on the panels where you want record navigation so admin and tenant panels don't force the behavior on each other.
• Resource-level control. Apply the navigation trait/mixin to specific resource pages when only some resources should be navigable, rather than enabling globally.
• Custom header actions. Header actions are cached by the plugin and re-applied to the swapped record. Use this to keep a "delete", "replicate", or custom action bar consistent while stepping records.
• Ordering. The nav order typically follows the resource's table query/default sort; set an explicit sort on the resource so "previous/next" is deterministic.
• Scoping. Navigation respects the resource's Eloquent query, so tenant/where scopes on the resource naturally restrict which records are reachable — keep the resource query as the single source of truth.
• Integration with policies. Authorization is still checked by the resulting page; make sure view/edit policies are consistent or records will appear in navigation but fail to open.

Gotchas and Tips

• v2.2.2 fixes cached header actions. In v2.2.1 and earlier, cacheHeaderActions was not re-run after navigating to a new record, so header actions could reflect the previous record (wrong state, stale closures, or missing actions). If you build actions dynamically from $this->record, upgrade to ≥2.2.2 and clear the view cache (php artisan view:clear, php artisan optimize:clear).
• Don't rely on header actions being computed once. Treat them as re-evaluated per record; keep closures pure and free of boot-time side effects.
• Deterministic ordering matters. Without a stable sort on the resource query, previous/next can skip or repeat records.
• Record swapping vs. redirects. Navigation swaps the record in place; any state you cache on the page (filters, form state, table selection) may survive the swap — reset it explicitly if that's not desired.
• Debugging. If navigation stops responding, check the resource query scopes and the generated record URLs first; the plugin defers to the resource for routing and authorization.
• Multi-panel / multi-tenant. Plugin config is panel-scoped; verify tenant scoping on the resource query rather than relying on the plugin to filter.
• Extension point. Customizing header actions or nav labels is done through the plugin/resource config — prefer that over overriding page classes so future bugfixes (like 2.2.2) apply cleanly.