Weave Code
Laravel Trailing Slash Laravel Package
backstage/laravel-trailing-slash
A Laravel package for controlling trailing slash behavior on your application's routes, letting you normalize, redirect, or enforce trailing slashes consistently. Keeps URLs canonical, avoids duplicate-content issues, and helps prevent mismatched redirects with simple, configurable middleware.
Use Laravel explicitly with or without trailing slashes, controlling URL generation and proper redirects for SEO.
Frequently asked questions about Laravel Trailing Slash
- How do I install backstage/laravel-trailing-slash in a Laravel app?
- Install it with Composer using composer require backstage/laravel-trailing-slash, then publish the config file if you want to customize path rules. Register the middleware in your HTTP kernel or apply it to specific route groups. The package has no dependencies beyond the framework, so installation is just Composer plus middleware registration.
- Which Laravel and PHP versions does this trailing slash package support?
- The package does not publish a clear version matrix, so confirm supported Laravel and PHP versions on the repository before adopting. It is described as lightweight with no dependencies beyond the framework, which suggests modern Laravel on PHP 8.1+, but that is not a guarantee. Check whether CI runs a test matrix against the Laravel versions you actually deploy.
- How do I force trailing slashes on every Laravel route?
- Enable the middleware globally and set the config to enforce the trailing-slash form rather than stripping it. Incoming request URIs are normalized and non-canonical URLs receive an automatic 301 redirect to the preferred shape. Start on a single route group and expand once you have verified generated URLs match the policy.
- How can I exclude specific paths or route groups from trailing slash normalization?
- The package ships a publishable config with configurable include and exclude paths, so you can limit normalization to marketing pages while leaving admin, API, or webhook routes untouched. Exclude anything with signed URLs or non-idempotent methods first. Keeping the exclude list explicit is safer than a global on switch during rollout.
- Does the middleware use 301 or 308 redirects for POST and PUT requests?
- The package advertises automatic 301 redirects, which are correct for GET and HEAD but can silently downgrade a POST to GET in many clients. If you have non-idempotent endpoints, scope normalization to GET and HEAD routes or confirm with the maintainer whether a 308 path exists. Test forms and API endpoints before enabling it application-wide.
- Will trailing slash redirects break Laravel signed URLs?
- Potentially yes. Laravel's ValidateSignature middleware signs the full path including the trailing slash, so rewriting a signed URL before validation produces 403s on password-reset and signed-asset links. Normalization must not rewrite already-signed requests, and signed routes are usually best excluded. Test every signed endpoint explicitly after enabling the middleware.
- Are query strings preserved when the package redirects to the canonical URL?
- The redirect should preserve query strings so campaign parameters, pagination, and filters survive canonicalization, but the documentation is thin enough that you should verify it. Test with UTM parameters, multiple query keys, and paginated URLs. Fragments never reach the server, so they are handled by the browser.
- Does the package work with route:cache, config:cache, and Laravel Octane?
- Treat this as unverified. If the package hooks route registration or the URL generator, php artisan route:cache may bake in one behavior locally and differ in production, and long-lived Octane workers can leak configuration across requests. Run route:cache and an Octane smoke test in staging before shipping. These are the edge cases a low-maturity package is least likely to have exercised.
- Does it change URLs generated by route(), url(), and action()?
- The package claims integration with Laravel's router and URL generator, so route(), url(), and action() output should follow your canonical policy. Verify that in views, sitemaps, transactional emails, queued jobs, and API responses, since mismatches surface there first. Also confirm it composes with URL::forceScheme() and forceRootUrl() behind a proxy rather than replacing them.
- What are the alternatives, and is this package production-ready?
- Alternatives include a hand-rolled normalization middleware, which is often only a few dozen lines, or rewrite rules at the Nginx or CDN edge. The package is a legitimate reference implementation but currently shows zero stars and single-maintainer provenance, so treat it as a pattern to vendor rather than a dependency you inherit. Budget one to two days of engineering plus crawl validation, and pin the version if you adopt it.
Weaver
How can I help you explore Laravel packages today?