Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

andyg1's avatar
Level 6

Strangler pattern with Laravel - what folder structure?

I've been working on a legacy website for a client and development is so slow and painful that I've been pitching to move towards a modern framework e.g. Laravel

The website is hosting a blog/CMS (more or less from the root) and then the complex stuff (bookings and payments) runs through a folder off the root e.g. root.com/payments/

I want to leave the blog/CMS alone (seeing as all the blog/CMS stuff does not rely on the same authentication system as the customer facing stuff). But, where to install the laravel code?

The docs say don't install laravel outside the public folder (so, in this instance, I can't put it in the /payments/ folder to isolate it from the blog/CMS.

So, how would I go about solving this without creating more drama down the road?

Thanks

0 likes
2 replies
LaryAI's avatar
Level 58

To implement the Strangler pattern with Laravel while maintaining your existing legacy system, you can follow these steps to structure your project:

  1. Install Laravel in a Separate Directory:

    • Install Laravel in a separate directory outside of your current web root. This keeps the Laravel application isolated and adheres to Laravel's best practices.
  2. Set Up a Subdomain or Subdirectory:

    • You can configure your web server to serve the Laravel application from a subdomain (e.g., payments.yourdomain.com) or a subdirectory (e.g., yourdomain.com/payments). This can be done by setting up virtual hosts in Apache or server blocks in Nginx.
  3. Configure Web Server:

    • If using Apache, you can create a new virtual host configuration for the Laravel application. If using Nginx, create a new server block. Ensure that the public directory of the Laravel application is set as the document root.
  4. Routing:

    • Use Laravel's routing to handle requests for the new functionality. You can define routes in routes/web.php for the new features you are developing.
  5. Proxy Requests (Optional):

    • If you want to keep the URL structure consistent (e.g., yourdomain.com/payments), you can use your web server to proxy requests from the legacy system to the Laravel application. This can be done using mod_proxy in Apache or proxy_pass in Nginx.
  6. Database and Authentication:

    • If the new Laravel application needs to interact with the same database as the legacy system, configure the database connection in the .env file. You may need to write custom authentication logic if the systems need to share user sessions or authentication data.
  7. Gradual Migration:

    • Gradually migrate features from the legacy system to Laravel. As you develop new features or refactor existing ones, implement them in Laravel and route requests accordingly.

Here's a basic example of how you might set up an Nginx server block for a subdirectory:

server {
    listen 80;
    server_name yourdomain.com;

    location /payments {
        proxy_pass http://127.0.0.1:8000; # Assuming Laravel is running on port 8000
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    location / {
        root /path/to/legacy/system;
        index index.php index.html;
    }
}

This setup allows you to keep the legacy system intact while gradually introducing new features using Laravel. As you migrate more functionality, you can eventually phase out the legacy system entirely.

martinbean's avatar

@andyg1 Here’s how I’d approach it (and how I have done with similar re-platforming projects in the past):

  1. Create a new Laravel project.
  2. Rename Laravel’s public/index.php file to public/laravel-index.php
  3. Update the relevant rule(s) in your server configuration file
  4. Dump all the files there were in the root directory, in the Laravel public directory

You’ll now have a Laravel application installed. Any requests for actual files and folders (i.e. those in the public directory from the legacy application) will be handled. If there is no match, then the request will be passed to Laravel’s front controller (the renamed public/laravel-index.php file).

This will allow you to re-platform the project in a piecemeal fashion. You can take a file from the legacy application, create a controller action, and delete the old script once you’ve converted it. So over time, the number of files pertaining to the legacy application will decrease, whilst the number of Laravel-related files (models, views, controllers, etc) will increase.

2 likes

Please or to participate in this conversation.