PHP7 Resource Recap

PHP 7 is well on its way. RFCs are being implemented and polished, projects are being tested, libraries upgraded. Extensions are being modified, and the word is spreading. All that remains is getting the shared hosts on the upgrade bandwagon – the arguably most difficult part of improving the global state of PHP. In this article, we’ll take a look at some of the most important PHP 7 related resources and tips you should go through in preparation for the new version.

Rasmus’ box

Some months back, Rasmus Lerdorf created and uploaded a Vagrant box for testing on PHP 7. This box can be downloaded from Github. In case the instructions are confusing (they shouldn’t be), see Rob Allen’s post. The box boots up in minutes and has not only PHP 7 enabled, but can also very easily update to the most recent version of PHP 7, and to dozens of other PHP versions.

The box features a newphp command which instantly replaces the PHP version currently in use with another binary, pre-compiled on the box. So for example, typing newphp 55 in the box will switch from PHP 7 to PHP 5.5., allowing you to quickly run your code in another version. What’s more, each version has its own PHP extensions folder, so you can easily compile and install new extensions – they all end up in the right location, and won’t conflict with other PHP binaries.

In a way, it’s similar to DUnit which uses Docker containers to fire up different PHP versions for you to test on.

Other boxes and Testing

Use Rasmus’ box above, or if you’re using PuPHPet, they recently added PHP7 support. There are some caveats, but in general, it should work. Vaprobash and Phansible aren’t there yet, but here’s hoping.

If you’d like to roll your own, this Ansible playbook for Ubuntu / Debian might help, or just go full-shell and follow these instructions – the post also has tips on writing tests for the actual PHP build, so you can contribute to the language itself!

Testing for PHP7 on Travis not only makes sure your code works on the latest nightly without forcing you to manually update your PHP7 build, but also gives you some street cred to brag with – “My code is PHP7 ready!”.

Updating Extensions

Libraries, packages and apps aren’t the only that need testing, though. Like the March Newsletter said (to which you can subscribe via this form, btw), extensions are on the front lines. PHP7’s new extension API is different enough from the old versions that several extensions will need extensive rewrites to remain compatible.

With that in mind, the gophp7-ext page has been set up to ease the transition for most extension developers.

Hopefully, this will make it easier for projects like Zephir and the newly released Phalcon 2 to become 7-friendly as soon as possible (as the Phalcon team says, they’re already looking at the necessary PHP7 upgrades).

If you develop PHP extensions (maybe you started after reading some of our tutorials?) or know people who do – point them to the GoPHP7-ext page and have them bring their code up to par. If you can get them to write about the process, documenting the changes that needed to be done, please do point them my way and we’ll publish their findings (and pay them handsomely for them), so others can benefit from learning about the process.

Important Reading

Finally, let’s list some of the most important reading resources you should go through to get on top of the changes that are coming up.

What to Expect is the first post you should read. It’s a two-part series from Davey Shafik, which explains the upcoming changes in a down-to-earth way. It’ll list all the important accepted RFCs and display demo code for each, so you can see how they might affect your workflow on practical examples.

PHP7 at a Glance from none other than Zend is yet another excellent overview. It features all the RFCs listed with their potential impact on a developer’s life plus the chances of BC breaks (there are some in edge cases, but none certain).

Performance stats

Zend put out this impressive looking infographic on performance. It doesn’t have the benchmarked source code or the environment details, though, so take it with a grain of salt. (Link added May 14th, 2015)

Wrapping up

As you can see, there’s a lot of content to go through – and version 7 is still months away. We’ll be updating this list with new resources periodically, so make sure you check back from time to time – newly added posts will be put to the bottom of their respective list and tagged with the date of addition.

Do you know of any valuable resources we’ve missed? Want to write something for us? Let us know!

Bruno is a coder from Croatia with Master’s Degrees in Computer Science and English Language and Literature. He runs a cryptocurrency business at Bitfalls.com via which he trades crypto and makes blockchain tech approachable to the masses. He’s also an editor for SitePoint, and a developer evangelist for Diffbot.com.

What interests me the most are the large performance gains and smaller memory footprint per request. That is something almost worth bragging about.

Would you say the performance is so good, a JIT compiler isn't going to do much more? Or can there still be an improvement in performance with a JIT compiler? I noticed in the benchmarks PHP7 is comparable to HHVM, but what is never mention is if the HHVM JIT compiler is on or not and if not, what are the differences then? If the HHVM JIT is on, oh my. I am impressed.

Ok. I just read one of the articles you linked to and the author said PHP7's performance is on par to HHVM with the JIT compiler working. Now the question in my mind is, would having a JIT compiler help with performance or with the memory footprint.

It probably would help, yes, to a degree. But I think the focus now deserves shifting from performance to some more pressing matters. At these speeds, it's almost impossible for PHP to become the bottleneck. But making the built-in server a viable Apache/Nginx replacement - now that's something I could see as downright revolutionary.

I also read that article. Appserver has come some way since then. Installation was a breeze and I am wrapping my head around how to use the beans, servlets and other services. If you ask me, it is like a very light PHP framework on steroids.

Interesting, after Michael Morris's post here about mark_script_ready() I built a PHP app server. (In my limited tests so far it's 500% faster than not using the app server on a non-trivial application). Essentially, when you connect to the server via HTTP, Apache/NGIX/whatever all that does is run a minimal script that does nothing except connect to the app server and request the state rather than construct all objects, connect to the database then shutdown.

So far I've got great concurrency (it runs a server on each available thread) and maintains persistence so if your code does $num++ each time you visit a page $num goes up without getting reset.

So far I've got great concurrency (it runs a server on each available thread) and maintains persistence so if your code does $num++ each time you visit a page $num goes up without getting reset.

Which basically means, you can do different things at different times, instead of doing it all with each request. As Stefan points out in the video above, with Appserver, you don't have to run any bootstrapping scripts with each request. You can store such things (and many others) as a servlet, which start running at server startup and stays in memory until the server is stopped or restarted. It is sort of akin to the Tomcat web server for Java, from what I can tell.

Which basically means, you can do different things at different times, instead of doing it all with each request. As Stefan points out in the video above, with Appserver, you don't have to run any bootstrapping scripts with each request. You can store such things (and many others) as a servlet, which start running at server startup and stays in memory until the server is stopped or restarted. It is sort of akin to the Tomcat web server for Java, from what I can tell.

I've just put a post up in showcase with my implementation Take a look at the code, it's surprisingly simple!

A few weeks back, @Michael_Morris posted a topic where he suggested that creating/destroying objects on each HTTP request was wasteful. I posted a way of getting around that in the thread, I've built on that a little and come up with what I think is quite a nice implementation
The basic thought process behind this is that:
When you connect to the webserver all that does is run a very minimal script, it doesn't create database connections, construct large object graphs, render HTML or d…

With something like that, are you saying that instead of going through the normal steps of installing Apache and then PHP, you would just have one simple install of PHP only? In your mind, how would all of that fall into place from the perspective of shared usage?