17

I have a big PHP project in which I didn't use any framework (nor MVC pattern), and I want to gradually port it on Laravel with (almost) no downtime.
I'm searching for ways of making transparent the migration for pieces of code already ported to Laravel, while mantaining functional older plain PHP code.

For example, Laravel "overwrites" superglobals ($_GET, $_POST, etc.) using classes and methods, (ex. Input::get()). My plain PHP project of course makes direct use of superglobals. How can I overcome these "uncompatibilities" under Laravel without having to rewrite instantly all my PHP code?

Otherwise, if you think this task being too difficult, is there any PHP framework that, thanks to its internal structure, would make this task easier?

UPDATE:
The use of superglobals is still possible in laravel. I was getting a sneaky error: Laravel internally sets error_reporting to E_ALL and shows a custom error stack trace page even for PHP E_NOTICE, but without explicitly specifying the error level (that it is a NOTICE error), even if this was done by default by PHP error reporting message engine.

Let me say, for Laravel core developers, that I consider this "partially silent" behaviour as generally misleading for any PHP developer trying to port his code on to their framework.

Matteo-SoftNet
  • 531
  • 3
  • 10
  • 1
    You can still use the PHP superglobals ($_GET, $_POST, etc.) inside your Laravel app. – SUB0DH May 05 '14 at 09:11
  • Thanks, your comment lead me to the solution. I updated my question accordingly. – Matteo-SoftNet May 05 '14 at 09:35
  • 1
    how is your project structured ? do you use any separation of presentation layer from business logic layer ??? – Gadoma May 05 '14 at 10:14
  • 1
    @DotMat - Laravel intentionally sets the error level, because you control it via a config file in app.php. Turn debug on/off and use as needed. You can also log different errors as needed – Laurence May 05 '14 at 10:51
  • @theshiftexchange - Yes, but the point is: why not to report the error level in the default stack trace page?? Nonsense. – Matteo-SoftNet May 05 '14 at 14:20

1 Answers1

29

TL;DR

Don't do this.

Common misconception

If you have an existing project, then grafting it on a framework will gain you no benefits. Frameworks are not some magic sauce, which miraculously makes the code better or make the site run faster.

Instead, frameworks are tools, that (supposedly) help you write the project in a shorter amount of time by having the "common tasks" already done. Also, as a side effect, it is extremely difficult to stop using a framework in a project (if it, for example, gets discontinued), because all of your code now is tightly welded to a framework.

This is why you are currently having these problems:

  • How can I overcome these "uncompatibilities" under Laravel without having to rewrite instantly all my PHP code?

    You cannot. Rewrite it exactly as the Laravel framework wants you to or it won't work.

  • (..) is there any PHP framework that, thanks to its internal structure, would make this task easier?

    No, there are not. All the popular frameworks will want you to rewrite your code so that it is bound to a framework.

The better approach

But you already have a working application. You will have better results, if you focus on improving the existing code base:

  • make sure you follow SOLID principles
  • separate your business logic from you presentation and database abstraction
  • start adding unit tests for the really shady parts of your code
  • refactor, refactor, refactor

P.S.: the materials listed here wold probably help

Community
  • 1
  • 1
tereško
  • 58,060
  • 25
  • 98
  • 150
  • Shouldn't developers be doing all of this already. These are common coding practices, though very good to mention not contributing to answering the author's question. – sidneydobber May 05 '14 at 12:26
  • 1
    @sidneydobber A lot of people don't do as they should. These days, I'm prone to assuming non-adherence to best practices, but maybe that's just jaded ole' me. – Dan Lugg May 05 '14 at 13:20
  • @Dan Lugg you're right on that! There are simply more devs popping up and good devs need to show them clean and crisp code with a good dose of positive reinforcement! ;) – sidneydobber May 05 '14 at 14:17
  • Thanks for your opinion (and your final link), this gave me a new sight about the problem. Now I'm undecided about the idea to gradually porting the project to an MVC framework. If backward compatibility could be not too hardly reached, the MVC structure imposed by a modern framework may be a big help in order to mantain best coding practices. And this is the point, for me: force myself to code well, avoid being too confident on my own skills and resources, while assuring the right flexibility for the future. This remains, indeed, a big question. – Matteo-SoftNet May 05 '14 at 14:18