- What is laravel-saved-filter used for?
- It lets you persist named filter configurations such as search terms, sorting, column selections, or query scopes in the database and reapply them to Eloquent queries later. Typical uses are saved searches on dashboards, reusable admin listings, and per-user views of large tables. Instead of rebuilding filter state on every request, you restore it from storage and apply it to the query.
- How do I install jeffersongoncalves/laravel-saved-filter?
- Install it with composer require jeffersongoncalves/laravel-saved-filter, then publish the package's config and migration stubs with vendor:publish and run php artisan migrate. Laravel package auto-discovery registers the service provider, so no manual entry in config/app.php is needed. Confirm the saved filters table exists in your database before wiring it into your controllers.
- Which Laravel versions does this package support?
- It is built for modern Laravel and relies on standard package features: auto-discovery, publishable migrations, and a service provider. Check the illuminate/database and php constraints in its composer.json for the exact supported range before installing. After upgrading Laravel, run your test suite against the saved filter flows to catch any query builder changes.
- How do I publish the config and migrations for this package?
- Use artisan vendor:publish with the package's saved-filter-migrations tag for the schema and the matching config tag for the configuration file. Re-running the migrations publish is safe in recent releases: only missing stubs are copied and existing files are skipped unless you pass --force. Verify on staging after each upgrade so you know exactly which stubs your application has run.
- How do I apply a saved filter to an Eloquent query?
- Resolve the saved filter record for the current user and model, then pass its stored configuration to your query builder so the saved criteria, sorting, or scopes are applied before pagination. The fluent API keeps this to a short chain rather than manual array handling at each call site. Keep the apply step in a query scope or action class so the same logic is reused across controllers and API endpoints.
- Can filters be stored per user, per model, or per tenant?
- Yes. Ownership resolution is configurable, so a filter can belong to the authenticated user, to an Eloquent model, or to a custom owner class you define. In multi-tenant applications, include the tenant in the owner resolution so saved filters never leak across tenants. Always enforce an ownership check when loading a filter, rather than trusting an ID from the request.
- Can I change the table name or swap the saved filter model?
- Yes. The table name, the saved filter model, and the ownership resolution are all set in the published config file. Point the model key at your own subclass if you need extra relationships, casts, or accessors, and update the table key if your schema conventions differ. If you rename the table, keep the published migration in sync so fresh installs and existing environments match.
- How does this compare to spatie/laravel-query-builder or building saved searches myself?
- Query builder packages parse and apply request filters on the fly, while this package adds persistence so a filter set can be named, stored, and restored per user or model. They complement each other: build the query with a query builder, save the configuration with saved-filter, and reapply it later. Hand-rolling is fine for one endpoint, but ownership, naming, and reuse usually make a dedicated package cheaper over time.
- How do I test saved filters in my application?
- Run the package migrations in your test suite with RefreshDatabase, create saved filter records for your test users, and assert that applying a filter returns the expected rows. Add cases where a user tries to apply another user's or tenant's filter and confirm it is rejected. If your stored payload format evolves, include legacy payload fixtures so older saved filters keep working.
- What should I check before deploying saved filters to production?
- Treat releases like any third-party dependency: re-publish the migration stubs, run migrate before deploying code that depends on new columns, and confirm on staging which stubs your application has already applied. Because saved filters are user data, back up the table and test applying stored payloads after upgrades. Pin the version in composer.json and read the changelog between minor releases for schema or API changes.