PHP 7 is now available! Find out what’s new.

PHP 7 is now available! Find out what’s new.

PHP7 Whats new

Yesterday, the PHP development team finally announced the moment many of us have been waiting for – the first stable release of PHP 7 – and there are many interesting new features and changes.

Where’s PHP 6?

At the time PHP 6 was under development, one of the major new features underway was to bring native Unicode support to PHP. This project alone caused significant delays in the overall progress of PHP 6 due to technical challenges. It was later decided to postpone the native Unicode project and merge the other new features that were originally intended for PHP 6 into a new version of the PHP 5.x branch.

Here is where the problem lies: many books on PHP 6 were published at the time it was under development. An unfortunate mistake for publishers to make, because features can and do change before feature-freeze.

So for a number of reasons, the PHP development team decided to skip PHP 6 entirely and start again with PHP 7.

What’s new in PHP 7?

We’ll be covering the new features that the developers amongst you will be interested to learn about. You can find a simple summary of the changes in PHP 7 and how you can upgrade in the Migrating from PHP 5.6.x to PHP 7.0.x manual on the PHP website.

Should I upgrade now?

Before we answer this question, it is worth mentioning PHP 7 was originally scheduled for release on November 12 but was postponed by two weeks due to some last-minute bugs that the PHP development team wanted to fix beforehand (and then postponed again on November 26). This should serve as a testament to the kind of quality to expect.

For test environments, you should definitely upgrade as soon as possible so you can start testing your web applications against it. There are indeed changes in PHP 7 that may cause compatibility issues with a small subset of web applications – so don’t blindly upgrade to PHP 7 on a production environment until you are at least confident your web application works flawlessly under PHP 7, as it is a substantial upgrade from PHP 5.6 with many new features and changes.

Now the inevitable question: should I upgrade my production environment? While PHP 7 is now “stable”, it might be a bit premature to upgrade just yet because there might be unknown bugs or vulnerabilities that are only spotted now that PHP 7 is in the wild.

It might be wiser to wait at least a couple months and in the meantime trying out the new version on a test environment to verify its compatibility with your web applications – deciding from there.

Upgrading to PHP 7 on GNU/Linux distributions

For some distributions that favour stability over new features, you might not be able to upgrade to PHP 7 until the distribution maintainers bring out a new stable release. For Debian in particular, this might not be until 2017 – the usual period between stable releases appear to be roughly every two years. And from what we’ve heard, PHP 7 won’t be made available in Debian backports.

Other distributions like Arch Linux and openSUSE should see PHP 7 hit the repositories in the near future.

In all cases of course, you can always compile and install PHP yourself if you are eager to try it now. This is certainly the route you’ll need to take if you are running Debian 8 or CentOS 7.

So let’s get to the exciting parts… what’s new in PHP 7?

PHP 7: 2x faster than PHP 5.x

Thanks to a group of Zend developers working on PHPNG – a development branch of PHP that was originally created to experiment with a JIT (Just In Time) engine – PHP 7 benefits from up to 2x faster performance over PHP 5.x.

This branch, later merged into PHP 7, features significant performance improvements in memory management. No, PHP has not become a JIT engine. If you’re interested in that, take a look at HHVM.

Speaking of which, the good folks at did some benchmarking between PHP 7 and HHVM. To the surprise of many – and us too – PHP 7 was found to have better performance in all the tests conducted except memory footprint.

PHP 7: Return Type Declarations

One for the programmers: you can now define the expected return type of any function or method. If the returned type is not the same as the one declared, an E_ERROR is thrown. Defining a return type is simple:

function returnInt(): int
    echo 42;

Now it might sound strange for an interpreted scripting language to introduce return type declarations, but imagine how beneficial this will be for object interfaces – it provides assurance that any implementing class will never return unexpected values – and likewise for classes that inherit abstract classes.

PHP 7: Deprecation of PHP 4 constructors

Creating constructor methods in PHP 4 involved defining a normal method that used the same name as the class it resides in. It wasn’t until PHP 5 saw the introduction of the __construct() magical method to perform the same function.

Of course, PHP 4 style constructor methods are supported in PHP 5.x for backwards compatibility, but will raise an E_DEPRECATED notice in PHP 7.

You can hide these notices in your php.ini configuration file, but this shouldn’t be relied upon because PHP 4 constructor methods are scheduled for complete removal in PHP 8. From this point on, these methods will act like any other normal method and will not be immediately executed when the class is initialised.

PHP 7: Removal of alternative PHP tags

To little surprise, the PHP development team have removed support for ASP- and HTML-style PHP tags, which includes:

<% opening tag
<%= opening tag with echo
%> closing tag

If your scripts rely on these alternative PHP tags, you’ll need to replace these with the standard PHP opening/closing tags, which are:

<?php opening tag
<? short opening tag (requires short_open_tag enabled)
<?= opening tag with echo
?> closing tag

PHP 7: Anonymous Classes

In PHP 5.x, we can create anonymous functions (also called closures) like this:

$var = function() { … }

echo function() { … }

A closure is simply a normal function that hasn’t a name defined. It’s useful for executing logic that returns a value at the end, but has other practical uses too.

New in PHP 7 is the ability to create anonymous classes in the same way you can create anonymous functions. It’s just as easy – here’s a brief example:

$class = new class {
    public function getDate() {
        return date('F j, Y g:i a');

PHP 7: Combined Comparison Operator

Dubbed the “spaceship operator,” this returns either 1, 0 or -1 depending on whether both operands are equal to, or if one is greater than or less than the other. That might sound like a handful – but it’s really rather simple. Here’s an example:

if(1 <==> 1) // 0

if(1 <==> 0) // 1

if(0 <==> 1) // -1

This becomes useful in a number of scenarios e.g. for sorting arrays with usort().

PHP 7: Null Coalescing Operator

This is a really handy new ternary operator – it allows us to return the first operand if it exists or is not NULL, or else its second operand.

This might sound very similar to the short ternary ?: operator – and it is – but the problem with that is an E_NOTICE error will be raised if the value being checked does not exist; Here’s how the new null coalescing operator works:

$username = $users->username ?? 'Guest';

What didn’t make it to PHP 7?

There were many features and changes that were tabled for inclusion in PHP 7 that were either rejected or stalled either due to the author withdrawing or lack of consensus.

One of the big changes that I was hoping to see approved for PHP 7 was the addressing of inconsistent PHP function names – and this was added as an RFC in March 2015, but has not moved from discussion stage since it was created.

I contacted the author of this RFC to ask about the progress and from what the author has told me, it looks like we might see movement in this RFC starting early next year.

So what does this RFC intend to address? The main purpose of the RFC is to create alias functions that are more consistently worded. For example all GD functions use cryptic function names like imagecreatetruecolor() and imagecreatefromgd2part(), and some are less cryptic but clearly inconsistent, like image_type_to_extension() and image_type_to_mime_type().

In the case of the functions above, the RFC proposes to create more consistently-worded alias functions like gd_create_true_color(), gd_create_from_gd2_part(), gd_type_to_extension() and gd_type_to_mime_type(). It’s also good to point out the changes this RFC is proposing are completely backwards-compatible, because they will simply be aliases and not sudden drop-in replacements.

Ben Stones


Leave your comment

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