PHP7: Easiest Upgrade Yet

With PHP7 looking increasingly stable (relatively speaking, it’s still pre-alpha so it’s VERY early days and anything could happen!), and work going well on the GoPHP7-ext project to get extensions converted, I have been thinking about the migration guides we’ll need to help people upgrade their existing applications. To this end, I took the simplest project I currently have (http://api.joind.in) and gave it a whirl on PHP7, using Rasmus’ PHP7 dev box. The result:


All in all, it wasn’t a great study of what kinds of things can go wrong when upgrading projects, because as far as I can tell with the test coverage that we have, it Just Works (TM).

I think the main reason for this success is that this project doesn’t use many (any?) dependent libraries. Those libraries are catching up fast to PHP7 but you will probably need to update to the newest versions of everything prior to doing a PHP5 to PHP7 platform upgrade. If your project uses libraries that aren’t already working on PHP7, check if they already have a branch for updates and use that in your testing (see also: Use a GitHub Branch as a Composer Dependency). If you can still break it, we love you!! Please immediately file a bug with a replication case and keep trying to break it if/when fixes are supplied. NB: this is open source, you may well need to fix things yourself.

So what kind of project will “Just Work” on PHP7?

  • Smaller codebases are more likely to upgrade without issues, they are also much easier to debug!
  • Older codebases are also likely to be fine! We’re removing the PHP4 style constructor but the majority of those simple PHP4-style MVC applications will probably run fine on PHP7. It’s the PHP 5.3 generation with lots of automagical things and huge full stack frameworks that will be a problem.
  • Code created with modern component frameworks and running on PHP 5.5 or PHP 5.6 will probably upgrade without much fuss
  • Projects with test coverage (unit tests, integration tests, all kinds of tests) will fare best, because it’s much more likely that any issues will be found before it’s a live environment problem.

After this failed experiment of what to look out for when upgrading a codebase, I’ll be following up with my findings on other upgrades and sharing what to look out for. If you’re starting to test how your code runs on PHP7, then I’d be interested to hear how you get on – please leave me a comment.

9 thoughts on “PHP7: Easiest Upgrade Yet

  1. > It’s the PHP 5.3 generation with –> lots of automagical things <– and huge full stack frameworks that will be a problem.

    Like what?

  2. “It’s the PHP 5.3 generation with lots of automagical things and huge full stack frameworks that will be a problem.” I tend to disagree there, actually, for one of the other reasons you stated: “Projects with test coverage (unit tests, integration tests, all kinds of tests) will fare best, because it’s much more likely that any issues will be found before it’s a live environment problem.” Most full stack frameworks fall under that latter bullet point, and have copious tests. We found that prepping both ZF1 and ZF2 for PHP 7 was relatively easy due to the number of tests; there were very few places where code was incompatible, and the tests helped find those few spots.

    • Oh the frameworks won’t be the problem, they will be solid. It’s the applications built upon them that I’m making sweeping generalisations about here.

  3. Pingback: PHP Annotated Monthly – June 2015 | JetBrains PhpStorm Blog

  4. Pingback: PHP 7 migration audit with Exakat Engine - Exakat

  5. Pingback: Everything You Need to Know about PHP 7 - Application Performance Monitoring Blog | AppDynamics

  6. Pingback: June 2015 Newsletter - Nomad PHP

  7. Pingback: Everything You Need to Know about PHP 7 | Curious Coder

Leave a Reply

Please use [code] and [/code] around any source code you wish to share.

This site uses Akismet to reduce spam. Learn how your comment data is processed.