Download the PHP package movor/laravel-db-redirector without Composer
On this page you can find all versions of the php package movor/laravel-db-redirector. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Informations about the package laravel-db-redirector
Laravel DB redirector
Manage HTTP redirections in Laravel using database
Manage redirects using database rules. Rules are intended to be very similar to Laravel default routes, so syntax is pretty easy to comprehend.
:heavy_exclamation_mark::heavy_exclamation_mark::heavy_exclamation_mark: MOVING GIT REPOSITORY :heavy_exclamation_mark::heavy_exclamation_mark::heavy_exclamation_mark:
This package repo and maintenance will continue on:
:truck: :truck: :truck: :truck: :truck: :truck: :truck: :truck: :truck: :truck: :truck: :truck: :truck: :truck: :truck:
Compatibility
The package is compatible with Laravel versions >= 5.1
Installation
Install the package via composer:
The package needs to be registered in service providers:
Database redirector middleware needs to be added to middleware array:
Run migrations to create table which will store redirect rules:
Usage: Simple Examples
Creating a redirect is easy. You just have to add db record via provided RedirectRule model. Default status code for redirections will be 301 (Moved Permanently).
You can also specify another redirection status code:
You may use route parameters just like in native Laravel routes, they'll be passed down the road - from origin to destination:
Optional parameters can also be used:
Chained redirects will also work:
We also can delete the whole chain at once (3 previous redirect records in this example):
Sometimes it's possible that you'll have more than one redirection with the same destination. So it's smart to surround code with try catch block, because exception will be raised in this case:
Usage: Advanced
What about order of rules execution when given url corresponds to multiple rules. Let's find out in this simple example:
To solve this problem, we need to agree on simple (and logical) rule prioritizing:
Priority 1: Rules without named parameters have top priority:
Priority 2: If rule origin have named parameters, those with less named parameters will have higher priority
Priority 3: If rule origin have same number of named parameters, those where named parameters are nearer the end of the rule string will have priority
So lets examine our previous case, we have:
- "/one/{param}/three" => "/four"
- "/{param}/two/three" => "/five"
In this case both rules have the same number of named params, but in the first rule "{param}" is nearer the end of the rule, so it will have priority and we'll end up at "/four".