Make an existing php project coexisting with Laravel

@leste I’d try putting Laravel in its own directory (underneath the webroot) and then renaming its index.php file to something like index-laravel.php. Then modify the .htaccess to either try finding a script in your old codebase, otherwise passing the request through index-laravel.php.

Just use laravel for all.

The best way to do this depends on how the legacy application is structured.

It sounds like your legacy project does not have a single point of entrance front controller (like Laravel's index.php) but has php files directly in the webroot that are accessed directly.

In this case it is easiest to move the files from the legacy project into the public directory. The suggested method of renaming the Laravel index.php file and changing the Laravel .htaccess rewrite rule will work fine. Alternatively you can convert the legacy index.php script into a Laravel controller so the old one wont be needed anymore.

You should be able to open both .htaccess files and move anything necessary from the legacy project into the Laravel .htaccess if nothing conflicts with each other.

Things get a little more complicated if your legacy project also had a single point of entry like Laravel (and most any mvc framework).

In that case the best way I have found is by letting Laravel control the routing and adding and exception handler or middleware that when a 404 would be sent by Laravel includes the bootstrap for the legacy project and lets it take over.

As great a Laravel is for new project I will admit it is not necessarily the best choice for a gradual upgrade like this as opposed to a complete rewrite.

A less opinionated more do it yourself type framework like Slim will let you reuse more of the legacy code as well as let you upgrade certain parts of the old project before you even introduce a new framework.

Generally the first step would be to introduce composer and an autoloader into the legacy project if it doesn't already have one then a Dependency injection container (I really like league/container http://container.thephpleague.com/ for non-Laravel applications).

You can then start doing stuff like adding models and moving database queries into them and having a standardized way of loading config data (illuminate/config is still great here along with vlucas/phpdotenv for a very Laravel familiar feel).

You can pull in blade or twig for your views and convert the existing html to start using it to render views.

Once you've got most of the pages mostly just pulling data from models, passing things off to domain objects, then rendering some type of view just like a typical controller would do you can add an mvc framework and start moving your php scripts into routes and controllers still using the same objects and code and rendering the same views.

This lets you slowly modernize the legacy project over a long period of time bit-bit, layer-by-layer. You wont ever have the issue of having an "old" application and a "new" application that are separate codebases and have to duplicate work on both for new features. The cost can also be spread out over a long time rather than trying to convince a client or a boss to pay for a rewrite.

Note that one of the most important things to do is to make sure to add tests as you go as when dealing with legacy projects who knows what could break.

Hi again !

Thanks for the answers !

Haven't dig into them yet (too early) but i'll try something based on your answers and let you know !

Valentin