Laravel Sorting Laravel Package

Getting Started

• Install the release with composer require (or composer update if already present) and confirm you are on 0.1.11; the fix only matters on Laravel 13 / symfony/http-foundation 7.4, where Request::get() is deprecated.
• Look first at the place you currently read the sort query parameter — usually a controller, form request, or a Sortable trait/concern. The package now reads it internally via input(), so any custom code still calling $request->get('sort') should be migrated to $request->input('sort') to stay deprecation-free.
• Fastest first use case: wire the endpoint to accept ?sort=name and ?sort=-created_at, return the sorted collection with pagination, and assert the ordering in a feature test. This proves the happy path before you add allowlists or multi-column sorting.
• If the package exposes config (sortable columns, default sort, parameter name), publish it with php artisan vendor:publish and set your default sort early — the new fallback behaviour relies on that default being sensible.

Implementation Patterns

• Controller-level sorting: pass the request straight into the package's query/sort builder rather than hand-parsing sort. Keep the parameter name in config so front-end and back-end agree.
• Allowlist before applying: map the incoming sort string to a whitelist of columns/relations. Even with the type guard from 0.1.11, an unknown-but-string column should not reach the query builder.
• Descending convention: keep the - prefix (or your configured convention) consistent across Blade tables, Inertia props, and API clients; generate the toggle links from a single helper so the UI and backend never drift.
• Combining with filters and pagination: apply filters first, then sort, then paginate, and append withQueryString() on the paginator so ?sort= survives page changes.
• Form requests for validation: validate sort as nullable|string (plus an in: rule against the allowlist) at the edge. This makes the array-parameter case an explicit 422 in your API rather than a silent fallback.
• Testing: add feature tests for ?sort=name, ?sort=-name, an omitted parameter, and ?sort[]=name. The last one is the regression that 0.1.11 fixed — assert it returns the default ordering and a 200, not a 500.
• Upgrade path: if you are moving to Laravel 13, grep the codebase for ->get('sort') and request()->get( and replace with input(). Do this in the same PR as the package bump so deprecation warnings don't linger.

Gotchas and Tips

• Request::get() is deprecated, not removed: existing code keeps working on older Symfony versions, so deprecation logs are the only signal. Run your test suite with deprecations-as-warnings enabled in CI to catch this class of issue early.
• Array parameters are now safe but silent: ?sort[]=x returns the default sort instead of a TypeError. That is an improvement, but it means malformed client requests fail quietly — log or validate if you need visibility.
• Default sort must be defined: the fallback path depends on a configured/default sort. If none exists, you may get an unordered result set (and unstable pagination). Always set an explicit default, ideally a unique column like id as a tiebreaker.
• Multi-column sorting: ?sort=name,-created_at should be validated and mapped as a whole; don't assume a single column when parsing the string yourself.
• SQL injection surface: never interpolate the sort string into orderByRaw. Use the package's mapping or an explicit match/array lookup.
• Debugging ordering issues: dump the resolved sort (parameter, mapped column, direction) behind a debug flag or in a test assertion; most "sorting doesn't work" reports trace back to a mismatched parameter name or a stale cached config.
• Extension points: if you need custom sort semantics (e.g. JSON columns, related-model columns), extend the package's sort resolver rather than duplicating parsing logic in controllers — this keeps you on the supported input() path through future Laravel upgrades.