fdmind/ignore-query-strings
A lightweight Laravel package for ignoring query strings in requests and URL comparisons. Skip or strip parameters like utm_source, page, and filters so caching, routing, and matching stay consistent across URLs that differ only by query string.
Architecture fit. Unchanged in shape — a service provider plus request-pipeline middleware that normalizes or strips configured parameters before the cache layer computes its key. v3.0.0 improves architectural fit in two ways. First, URI path exclusions let the normalizer be scoped declaratively (marketing pages, blog, landing pages) rather than by middleware-group gymnastics, which directly addresses the earlier concern that the middleware should never be enabled on the authenticated or transactional surface. Second, default safe params (page, q) and default safe paths move the package from a bare mechanism toward an opinionated policy — convenient for adoption, but it means the package ships opinions about your cache semantics that must be reviewed rather than inherited. Fit is still strongest for teams doing full-page/response caching in Laravel; still near-irrelevant where the CDN owns normalization.
Integration feasibility. Still low effort on install, but the upgrade path is now materially different from the install path. In Laravel, mergeConfigFrom applies new package defaults to existing published config files unless the package replaces rather than merges — so upgrading to v3.0.0 can change cache keys with zero diff in the application repo. That is a silent behavior change and needs explicit handling. The policy decision still dominates the work: the parameter inventory must now be reconciled against the package's new defaults rather than written from scratch, which is faster but also means defaults can mask an incomplete inventory.
Technical risk. The dominant risk has shifted. It is no longer only "does it denylist or allowlist" — it is what "safe" means in "default safe params." If page and q are preserved (safe from stripping), the package now defaults to the correct, poison-averse behavior for the two parameters most likely to cause cross-user pagination and search leakage — a genuine improvement over the earlier unknown. If they are stripped (considered safe to discard), the package defaults to the single highest-severity failure mode identified previously, on the exact parameters that cause it. This must be verified by reading the source, not the release notes.
If q is preserved, a second-order risk appears: search queries are unbounded, so preserving q in the cache key reintroduces key-space cardinality and opens a low-cost cache-flooding vector (arbitrary query strings each minting a cache entry). That is a scaling regression relative to the prior baseline of collapsing everything non-semantic.
Path exclusions reduce blast radius substantially and are the most valuable change in the release. Regex escaping for param keys is a correctness/robustness fix and mildly positive maturity signal — someone hit a real edge case and fixed it. Major version bump with four terse bullets and no changelog detail is a maturity negative: four listed additions do not obviously constitute a breaking change, which implies either unlisted breaks or a loose versioning discipline. Ecosystem signal remains unchanged — still ~5 stars, 0 dependents, single maintainer — so the "no one else has hammered the edges" risk stands, offset by a code surface still auditable in under an hour and MIT terms permitting vendoring.
Key questions.
glie in "default safe paths for glie and cp"? Likely a typo, and hardcoded vendor-specific path defaults in a general-purpose package is a smell — are these the maintainer's own application's paths shipping as defaults?q create unbounded key cardinality, and is there an opt-out or normalization (lowercasing, length cap, param dropping) for search?URL::signedRoute and pagination links; whether the original query string survives for analytics.Stack fit. Unchanged: Composer package, service provider, publishable config, middleware; no migrations, queues, external services, or PHP extensions; works on Laravel 9/10/11 under PHP-FPM or Octane. Path exclusions make it a better fit for teams that want the normalizer confined to public marketing routes while leaving /checkout, /account, and /api untouched. Still redundant where Cloudflare/Varnish rules already normalize.
Migration path. Now three phases rather than two.
page, q, the "glie"/cp paths). Do not accept merged defaults implicitly./page?utm_source=x vs /page, /search?q=shoes&utm_source=x vs /search?q=boots, and a deliberately excluded path that must not be normalized.Expect a cache-key change and a temporary hit-ratio dip on upgrade — keys minted under v2 will not match v3, so treat the first post-deploy window as a cold-cache event and schedule it away from peak or paid-media flights.
Compatibility. Still verify against the actual cache implementation, not just "Laravel" — spatie/laravel-responsecache and Symfony HttpCache both key off the request URI, but confirm empirically. Middleware ordering remains load-bearing: the normalizer must run after anything that legitimately consumes a query parameter (locale detection, multi-tenant resolution, A/B assignment) and before the cache lookup. Path exclusion evaluation adds a new ordering consideration — if locale or tenant prefixes are applied by earlier middleware, an exclusion written as /blog may or may not match /en/blog. Verify against your real route shapes.
Sequencing.
page and q key behavior, excluded-path non-normalization, and signed-URL validity.Maintenance. Slightly higher than "near-zero." The release cadence is now demonstrated — the package is being developed, not abandoned — which is a genuine positive and reduces the "unpatched Laravel incompatibility" risk that dominated the prior assessment. But a 3.0.0 with four terse bullets and no changelog detail means every major bump requires source review, and the merge-config hazard means upgrades cannot be treated as routine composer update. Recommend pinning the version, vendoring the source (MIT permits this), or reimplementing, so the team is never blocked upstream and so config-merge surprises are impossible.
Support. Still no vendor, no SLA, no commercial backing, still a single maintainer. Assign ownership explicitly to whoever owns the caching layer. The maintained artifact is now two documents, not one: the parameter policy (each param, semantic or not, and why) and the path-exclusion policy (each included/excluded path and why). The second is new and is the one most likely to be edited under incident pressure.
Scaling. Still strongly positive — collapsing ?utm_source=facebook / ?gclid= variants onto one cache entry remains the core win on paid-traffic landing pages, and path exclusions extend the win to more routes without exposing transactional surfaces. The new caveat is q: if preserved by default, search pages generate one cache entry per distinct query string, which can reduce effective hit ratio and increase cache storage versus a strip-everything baseline. Quantify this per route — for most sites the right answer is to exclude search routes entirely rather than normalize them.
Failure modes.
page/q; if the opposite, this release made the default posture worse on the two highest-risk parameters.q: unbounded search-query cardinality inflates the cache and can be driven cheaply by an external party.Ramp-up. Still measured in hours, but the estimate moves from roughly one engineer-day to one to one-and-a-half days: the extra half-day is reading the source to resolve the "safe" semantics and path-matching behavior, plus the config reconciliation. Success metric is unchanged — cache-hit-ratio improvement on paid-traffic landing pages — with a new guardrail metric: no measurable increase in distinct cache keys per route after enabling, which catches the q cardinality regression.
How can I help you explore Laravel packages today?