- What does fdmind/ignore-query-strings do in a Laravel app?
- It is a request-pipeline package that ignores configured query string parameters when matching URLs and routes, so URLs like /page?utm_source=facebook and /page resolve to the same endpoint. This helps prevent cache-key fragmentation caused by marketing attribution parameters such as utm_*, gclid, fbclid and msclkid. It does not replace your caching layer; it changes how requests are matched before a cache computes its key.
- How do I install fdmind/ignore-query-strings?
- Install it with Composer using composer require fdmind/ignore-query-strings, then let Laravel package auto-discovery register the service provider. Publish the package config with php artisan vendor:publish and review the parameter list before enabling it. Register the middleware in the HTTP kernel or on the specific route groups where you want query strings ignored.
- Which query parameters does it ignore by default?
- The exact default list is defined in the package configuration, so publish the config and review it before production use. Typical targets are marketing and attribution parameters such as utm_*, gclid, fbclid and msclkid. Confirm whether the package treats the list as a denylist or an allowlist, and audit it against every query parameter your application actually consumes.
- Will this break Laravel pagination, filters or search?
- It can break those features if you ignore parameters that legitimately change the response, such as page, sort, q, locale or filter parameters. Keep semantic parameters out of the ignore list and test pagination link generation on affected routes. Enable the middleware on low-risk route groups first and compare responses before rolling it out widely.
- Does it work with Laravel response caching or spatie/laravel-responsecache?
- It operates at the request and URL-matching layer, so it can help any cache that computes keys from the full URL, including Laravel's own response cache and spatie/laravel-responsecache. Verify which cache layers it actually influences in your stack before relying on it. If you cache at the CDN or Varnish edge with your own normalization rules, the equivalent work likely belongs in the edge configuration.
- Is fdmind/ignore-query-strings compatible with Laravel 9, 10 and 11?
- The package is a standard Composer package with a service provider and middleware, but the README excerpt provided does not list supported Laravel versions. Check the Illuminate version constraints in its composer.json on Packagist or GitHub before installing. If the constraint blocks your version, the MIT license allows you to fork or vendor the small codebase.
- How does it interact with Laravel signed URLs?
- Signed URLs depend on the exact query string, so normalizing or stripping parameters before signature validation can invalidate them. Exclude signed routes from this middleware or ensure signature validation runs first. Test URL::signedRoute and the signed middleware explicitly in staging.
- Does it redirect users to the clean URL or only normalize the cache key?
- The package description focuses on ignoring query strings when matching URLs and routes, not on issuing redirects to a clean URL. Redirect behavior and canonical tag handling remain your application's responsibility. For SEO, pair normalization with correct canonical tags and confirm whether the request is mutated globally or only normalized for matching.
- How should I test this package before enabling it in production?
- Install it in staging behind a feature flag and log the original and normalized URLs side by side. Compare cache hit ratio and response variance before and after enabling the middleware. Add feature tests for pagination, locale switching, signed URLs and analytics parameter capture, then enable it on a low-risk route group first.
- Is fdmind/ignore-query-strings safe for production, and what are the alternatives?
- The logic surface is small and the MIT license permits auditing, vendoring or forking, but the package has low ecosystem maturity with few stars and no dependents. The main production risk is cache poisoning if you ignore a parameter that legitimately varies the response. Alternatives include custom middleware, CDN or reverse-proxy normalization rules, or configuring your response-cache package to normalize keys itself.