www.phparch.com March 2019 Volume 18 - Issue 3 Building Bridges We Need a Bigger Boat Migrating Legacy Web Introduction to Scaling, Part Two Applications to Laravel WordPress and the OAuth 2 IndieWeb How It Works, Refresh Tokens, Why You Should Own Your Voice and the State Parameter ALSO INSIDE Internal Apparatus: Security Corner: Hash Table Collisions Intrusion Detection Education Station: finally{}: Explicit is Better Than Implicit The Seven Deadly Sins of Programming: Envy Community Corner: Women in History Month PHP[TEK] 2019 Tickets Conference On Sale NOW! Save $200 A series of tracks dedicated to teaching you til in-depth information about a specific topic lead by hand-picked experts March 31st! chosen for their knowledge and presentation skills. A truly unique learning experience! May 21-23, 2019 ◆ Atlanta, GA tek.phparch.com CONFERENCE FEATURE Migrating Legacy Web Applications to Laravel Barry O’Donovan Thanks to Taylor Otwell’s Laravel framework, PHP is reclaiming its rightful place as the go-to language for web application development. For those of us maintaining and developing applications using legacy frameworks, the grass certainly looks greener on Laravel’s side. In this article, I show how to do an in-place migration from a legacy framework to Laravel. Introduction to make. For a commercial project, retain key employees and attract it puts a real cost on the migration: more developers. Let’s face it, as 1 IXP Manager is an open source (number of developers * monthly salary * developers we prefer to engage in 2 tool we developed at INEX for n months) + the opportunity cost of the projects that use current frame- managing IXPs (internet exchange development freeze where n will real- works and which support modern points—network switching centers istically be six months at an absolute versions of PHP (i.e., greater than which facilitate the regional exchange minimum. This estimate is tough to get or equal to 7.1). of internet traffic between different approved by the higher-ups! Plus, have 2. You have to eventually: this is a networks). It has run on Zend Frame- you ever met a development project corollary of the above point. If you work V1 (ZF1) since 2008. that finished on time? That six months do not migrate to a modern frame- Zend Framework 1 went end-of-life can creep to a year and even beyond work, then you inevitably face each in 2016, but its obituary was written a very quickly. of the following consequences. You couple of years before that. In 2015, we With the in-place migration, we add hemorrhage employees/develop- released V4 of IXP Manager which was Laravel to our application so that it ers, and your code grows more a framework transition release. Over has the first opportunity to service a outdated and consequently prove the course of nine minor releases of request (route). Otherwise, it hands off more difficult and costly to upgrade V4, we migrated from ZF1 to Laravel to the legacy framework. This approach eventually. You’ll be running on finally completing the project with V4.9 has two immediate advantages: you frameworks that have passed released in January of 2019. can develop all new features immedi- end-of-life and end-of-support Admittedly, a two and half year ately on Laravel as well as use Laravel which means security holes will be transition sounds like a long time, but features and facades within the legacy discovered but remain unpatched this was an in-place migration where framework. It also means you can and you’ll be forced to run older Laravel handled new and migrated migrate legacy controllers on a case-by- operating systems to run older controllers while anything still to be case basis as time and resources allow. versions of PHP for framework migrated fell back on ZF1. You should Migrating the smaller/simpler legacy compatibility yielding yet more also note the IXP Manager project has controllers are also excellent projects known but unpatched security a single full-time developer plus me for interns, student work experience holes. when time allows. or new hires getting up to speed. The 3. Develop with modern techniques real cost is buried in day-to-day devel- The Approach and services: Laravel makes it opment, there’s no promised flag-day incredibly easy to use modern There are two possible approaches to deadline to miss, and there’s no frus- features such as job queues, an migrating your application to Laravel: trating feature freeze. integrated command line inter- a flag-day or an in-place/side-by-side Making the Case face, broadcasting, caching, events migration. with listeners, scheduling, modern Your gut feeling may lean towards a Part of making the case to fellow templating engine, database flag day—“let’s just get this done”—but developers and decision makers in your abstraction, and ORM, and more. organization is being able to reference it is the more drastic path. It means 4. Reference applications: refer to that Laravel is now the number one web pausing all feature development and projects that successfully demon- application framework on GitHub3- – rewriting the application completely. strate an in-place migration across all languages. Other important In any project, commercial or open including IXP Manager which arguments include: source, this is a difficult argument supports critical internet infra- 1. Prevent developer apathy: or, structure in 70 locations around better phrased for management, 1 IXP Manager: the world and has successfully https://www.ixpmanager.org 3 web application framework on GitHub: 2 INEX: https://www.inex.ie https://github.com/topics/framework 8 \ March 2019 \ www.phparch.com Migrating Legacy Web Applications to Laravel completed the migration, and LibreNMS4, a hugely lines shown in Listing 2 to your composer.json file (ensuring popular network monitoring system with thousands of you match this to your version of Laravel). installations that is also well along the path of replacing a You should now run composer update to install Laravel and custom framework with Laravel. its dependencies. You should also examine the other sections Prerequisites Listing 1 Before you start the process of integrating Laravel for an 1. # Get the Laravel files from GitHub: in-place migration, you need to ensure your existing applica- 2. git clone https://github.com/laravel/laravel.git tion is ready for it. 3. Your legacy application needs to use Composer, a depen- 4. # Switch to the version of Laravel you want to migrate to: dency manager for PHP. If you are not using it already, you 5. cd laravel need to integrate it into your application by using autoloaders 6. git checkout vx.y.z (classmap, PSR-0/4) for existing namespaces (whether 7. 8. # Assuming you are in the new Laravel app directory above Zend_ modern PHP namespaces or the type prefix). 9. # and your legacy application is located at ../legacyapp Your application should have a single point of entry (e.g., 10. index.php). If it doesn’t, you can create an index.php to handle 11. # You can start to move the files as follows (and feel free this by (carefully and securely) examining the $_REQUEST 12. # to break this into smaller steps if there are conflicts): object and running the requested script from a new index.php. 13. mv app/ artisan bootstrap/ config/ database/ package.json \ 14. phpunit.xml resources/ routes/ server.php storage/ \ Your application entry point should exist in a dedicated 15. tests/ webpack.mix.js ../legacyapp subdirectory such as public/—i.e., your web server should 16. not expose the framework and other PHP files. This directory 17. mv .env.example ../legacyapp/.env layout should be relatively easy to retrofit if not already in 18. mv public/js/app.js ../legacyapp/public/js place. 19. mv public/css/app.css ../legacyapp/public/css 20. The Migration 21. # For now, we ignore public/index.php and we do not need 22. # any of composer.json, readme.md, vendor/ or CHANGELOG.md Step One: Install Laravel The first step is to install the Laravel application base files Listing 2 alongside your existing application files. Begin by installing 1. { Laravel5 using its documentation into a separate directory 2. "require": { and then move the files over to your application root direc- 3. "fideloper/proxy": "^4.0", tory in a piecemeal fashion. 4. "laravel/tinker": "^1.0", You need to resolve any filename or directory conflicts, and 5. "laravel/framework": "5.7.*" you should do this by moving your files out of the way and 6. }, renaming or refactoring them rather than altering Laravel’s 7. "require-dev": { files. The level of effort here is framework dependent, but the 8. "beyondcode/laravel-dump-server": "^1.0", 9. "filp/whoops": "^2.0", good news is that it was very easy for ZF1. I also looked at 10. "fzaninotto/faker": "^1.4", the file and directory structures for CodeIgniter and Symfony, 11. "mockery/mockery": "^1.0", and both also seem like they shouldn’t pose any significant 12. "nunomaduro/collision": "^2.0", problems. Lastly, if you are running a custom or non-appli- 13. "phpunit/phpunit": "^7.0" cation framework (LibreNMS was in this category), you can 14. }, still use the technique I am demonstrating here. Continue 15. "autoload": { reading and pay particular attention to moving but keeping 16. "psr-4": { your index.php in step two below. 17. "App\\": "app/" 18. }, When you complete the file moves as shown by example in 19. "classmap": [ Listing 1, examine any files remaining in the Laravel directory 20. "database/seeds", and move them if necessary/desired. Also, note the example 21.