- What does alengo/sulu-redirect-bundle actually do?
- It is a Sulu CMS bundle that maps legacy or removed URLs to their new destinations using permanent (301) redirects. The redirect table is CSV-driven and resolved early in the request cycle at the kernel.request event, so old links keep working after content restructuring. Redirects are created and edited inside the Sulu admin panel instead of config files, which keeps SEO value intact without a deploy for every change.
- Can I use alengo/sulu-redirect-bundle in a Laravel application?
- No. This is a Sulu CMS bundle built on Symfony, and it hooks into Symfony's kernel.request event and the Sulu admin UI, neither of which exists in Laravel. Laravel applications should use middleware, route fallbacks, or a package written for Laravel's HTTP kernel instead. If you are evaluating Composer packages for a Laravel app, this one is out of scope.
- How do I install alengo/sulu-redirect-bundle?
- Install it with Composer using composer require alengo/sulu-redirect-bundle, then register the bundle in your Sulu/Symfony application kernel or bundles configuration as described in the README. After registration, clear the cache so the new routes, services, and admin panel navigation are picked up. Check the repository's composer.json for the exact Sulu and Symfony version constraints before installing.
- Which Sulu and Symfony versions does this bundle support?
- Support depends on the version constraints declared in the package's composer.json, so check those against your project's Sulu and Symfony versions before requiring it. Sulu bundles are typically tied to a Sulu major version, and mixing incompatible majors will cause service or admin panel errors. Review the repository's release tags and README for the currently supported matrix.
- Do I have to edit configuration files to add a redirect?
- No. The main selling point is that redirects are managed from the Sulu admin panel, so editors and content managers can add, edit, or remove a 301 redirect without touching YAML or PHP files or triggering a deployment. That keeps redirect maintenance with the content team instead of developers. Configuration is normally only needed once, for registering the bundle and pointing it at its storage.
- How are the redirects stored, and can I edit the CSV directly?
- Redirects are persisted in a CSV file, which makes the data easy to export, review, diff, and migrate between environments. The admin panel is the intended editing interface, but the CSV can be edited directly if you respect its expected column structure. If you do edit it by hand, clear any relevant cache and verify the redirects still resolve as expected.
- Does it support 301 versus 302 redirects and wildcard or regex matching?
- The bundle is positioned around permanent 301 redirects, which is the correct status code for permanently moved content and the one that passes SEO value. Whether temporary 302 responses, wildcards, or pattern matching are configurable depends on the current release, so verify against the README rather than assuming. For anything beyond exact URL-to-URL mapping, test each case explicitly before relying on it in production.
- What is the performance impact of resolving redirects at kernel.request?
- Every request passes through the redirect lookup at kernel.request, so the cost depends on how the CSV is read and whether the result is cached. With a small or moderate redirect table and caching enabled this is normally negligible, but a very large CSV loaded on every request can add measurable overhead. Benchmark your real redirect volume with production caching enabled, and consider web server level rules if the list grows into the thousands.
- How should I test that a redirect is working correctly?
- Write a functional test that requests the old path and asserts a 301 status with the expected Location header, then requests the new path and asserts a 200. Also cover the admin panel flow so editors can add a redirect without breaking the CSV. Run the suite with caching configured the same way as production, since redirect resolution may behave differently with a cold cache.
- When should I use this bundle instead of nginx or Apache rewrite rules?
- Use this bundle when content editors need to own redirects, when the mapping changes often, or when you want a reviewable CSV history inside the Sulu admin rather than server configuration. Web server rules are still the better fit for large volumes, regex-heavy patterns, or redirects that must apply across multiple applications sharing a host. Many teams combine both: infrastructure-level rules for bulk patterns and this bundle for editorial, page-to-page moves.