Weave Code
Redirect Bundle Laravel Package
symkit/redirect-bundle
A Symfony bundle for managing URL redirects in your application. It helps you define redirect rules and integrate redirect handling cleanly into Symfony projects, making it easier to preserve links and route users to the right destination.
Symfony bundle to manage URL redirects (internal and external) from the database, with validation, route integration, and global search.
Frequently asked questions about Redirect Bundle
- What is symkit/redirect-bundle and what problem does it solve?
- It is a Symfony bundle for managing URL redirects, both internal and external, from a database instead of hardcoded configuration. It adds validation of redirect rules, integration with Symfony routing, and a global search so existing redirects can be found and maintained. It is most useful when content or marketing teams need to change redirects without waiting for a deployment.
- How do I install symkit/redirect-bundle with Composer?
- Install it with composer require symkit/redirect-bundle, then make sure the bundle is enabled in your kernel or bundles.php; Symfony Flex usually registers it automatically. You then point it at your Doctrine connection and create the table that stores the redirect rules, typically via a migration. After that, redirect entries can be managed from your own admin tooling or fixtures.
- Does symkit/redirect-bundle work with Laravel?
- No. It is built as a Symfony bundle and depends on Symfony's kernel, bundle, and HTTP kernel conventions, so it cannot simply be dropped into a Laravel application. In Laravel you would use framework-native middleware or a Laravel-specific redirect package instead. The shared piece is only that both are installed through Composer.
- Which Symfony and PHP versions does symkit/redirect-bundle support?
- Version support is defined by the require constraints in the package's composer.json and by its tagged releases on Packagist. Because it is a Symfony bundle, you should confirm that your Symfony and PHP versions fall inside those constraints before installing, especially when upgrading a major Symfony release. Checking the repository's CI matrix and recent release notes is the fastest way to verify.
- Can it redirect to external domains as well as internal URLs?
- Yes, the bundle is described as handling both internal and external redirects. Internal targets typically map to paths or route names inside your application, while external targets send visitors to another domain, usually with a 301 or 302 status. Make sure only trusted editors can create external rules, and validate target URLs to avoid open-redirect problems.
- Where are redirect rules stored, and can I edit them without deploying?
- Rules live in the database, so they can be created, updated, and disabled at runtime without a code deployment. That is the main advantage over hardcoding redirects in routing configuration or web server files. You will still want migrations, backups, and some validation workflow, since database edits bypass code review.
- How does it integrate with existing Symfony routes and controllers?
- The bundle hooks into request handling so an incoming request that matches a stored rule is redirected before it reaches a controller. Targets can reference route names, which keeps destination URLs in sync when your routing changes rather than duplicating hardcoded paths. Unmatched requests continue through the normal Symfony routing pipeline.
- What does the global search feature in this bundle do?
- Global search lets you look across all stored redirects to find rules by their source, target, or other attributes. It is useful for auditing large redirect tables, spotting duplicate or conflicting entries, and tracing chains before they cause loops. Its usefulness grows with the size of the redirect table, so it pairs well with good database indexes.
- How do I test redirects handled by this bundle?
- Use Symfony's WebTestCase or KernelTestCase to issue requests to source paths and then assert the response status code and Location header. Cover the important edge cases: an unmatched URL returning 404, disabled rules, external targets, and chains that could loop. If you cache redirect rules, add a test that verifies the cache is refreshed after a rule changes.
- What should I consider before using it in production, and what are the alternatives?
- Each request may trigger a database lookup, so index the source path column, watch for redirect chains or loops, and consider a cache layer for high-traffic sites. Alternatives include Symfony's native redirect configuration in routing, a small custom kernel or event listener backed by Doctrine, or other Composer redirect packages. Before adopting it, check the repository's recent commits, release cadence, and license to judge long-term maintenance.
Weaver
How can I help you explore Laravel packages today?