PHP 7: What if it’s already time to migrate?

In recent years, the minor releases of PHP have successively brought some significant improvements to the language's performance. The community around PHP has become more professional and has made numerous tools available to developers to improve the use of the language and application maintenance. Announced as a major event, the release of PHP 7, successor to PHP 5, is scheduled for November 12. Why is this considered as a major event? Let’s take a look under the hood of PHP 7.

(Re)discover the first chapter of the story:No, PHP is not dead!

PHP 5 to 7: A confusing transition

Are computer scientists angry with math? After Microsoft upgraded Windows 8 to Windows 10, PHP has in turn chosen to disregard the basic rules of arithmetics by following PHP 5 with version 7. This quirk can be explained by backtracking a bit. In 2004, after the release of PHP 5, the undertaking of version 6 began with the main goal of integrating Unicode into the language, allowing for the standardization of special characters. For example, without Unicode, we could not write “I ❤ PHP”.

Bad decisions and a lack of motivation drove the developers of PHP to stop working on this version in 2010. In his presentation, Andrei Zmievski outlines the technical details that lead to this choice. The developers were concentrating on more practical improvements and integrated them into the minor versions up to 2014.

When the PHP developers were working on the roadmap for the next major version, they quickly began to question how they should name it (see thedetails of the debate). Some articles and several books were released in the meantime, evoking ideas and visions of version 6, which was ultimately aborted, thus posing the risk of confusion for users seeking documentation on the latest version of PHP. Furthermore, the community was eager to finally put an end to this misadventure. This is why the developers overwhelmingly voted for the name "PHP 7".

This new version of PHP is the result of more than a year and a half of work and it is difficult to provide a comprehensive list of all the innovations that it brings along. In this article, we will focus on the most important points.

PHP 7: Two times quicker than PHP 5.6

Competition is often good a good thing. In order to meet its own needs, Facebook created back in 2011 a PHP runtime platform (called HHVM), which improved language performance by using a system which compiles on the fly (JIT). Inspired by this project, the community of developers quickly sought to integrate similar improvements directly within PHP.

Joined together under the name PHPNG (PHP New Generation), these optimizations required a major code refactoring but they paved the way for the integration of the JIT mechanism while improving the overall performance of the language. Under real conditions, PHP 7 is nearly two times faster than PHP 5. And if we rely on the benchmarks made by Rasmus Lerdorf (creator of PHP), last April PHP 7 reached the same level of performance as HHVM, thus driving the HHVM developers back to work on their project to retake the lead!

Some bloggers have been quick to state that the new version of PHP is just PHPNG. In reality, PHPNG’s impact is far from marginal but it is only part of the completed project.

Tests made with the web hosting offer Performance 1. Mesures in seconds.

PHP 7: From PHP 5 to PHP 7: make it or break it?

The arrival of PHP 7 has led to some of features marked as "deprecated" in older versions being unusable. Many extensions that have not been maintained have been eliminated, among them the ereg * extensions and MySQL extension, to be ideally replaced by the PDO MySql or mysqli extensions.

If you use non maintained PHP extensions, such as some that connect to specific databases, make sure that they’re supported by PHP 7. PHPNG has changed the inner workings of extensions and they must be updated to work under PHP 7. There is already a prototype driver available from MongoDB.

Always looking to improve performance, PHP now uses an « abstract syntax tree » (AST) enabling code optimization on the fly. However, this requires that the method for reading content be uniform. With PHP 5, the compiler reads from left to right most of the time, except in some cases with variables being read from right to left. These exceptions no longer exist with PHP 7 and all code is interpreted from left to right.

Take for example the variable “$foo->$bar['baz']”. In PHP 5, the interpretation of this variable can be written as “$foo->{$bar['baz']}”. However, in PHP 7, the interpretation can be written as “$foo->$bar”, with ($foo->$bar)['baz'] being interpreted first. This change shouldn’t have a major impact on your applications. However, do not be surprised if you encounter errors with such syntax.

Another significant change, and I think it's good news, is that “fatal errors” returned by the language are now returned in exceptions. This means that you can treat these types of errors directly within an application and avoid PHP’s default behavior. Those who have dealt with these errors know what I mean!

Finally, PHP includes new reserved words so beware because you can no longer use the following words to name your classes, namespaces or traits: int, foat, bool, string, true, false, null, resource, object, scalar, mixed, numeric. Many PHP frameworks have wrappers around certain data types, such as strings, and must be adapted.

The points discussed do not cover all issues concerning backward compatibility with PHP 5.6 but I believe they cover the most important ones. A complete list is available and can be found on the PHP site: Even if all precautions have been taken, nothing can replace testing under real conditions, for example on your pre-production infrastructure.

Avoid fatal errors with the typing of scalar settings

The new [url=" of PHP features"] is long and provides what is needed to effectively discredit people’s claims of PHP being dangerous because of its dynamic typing. For the first time in its history, PHP integrates static type variables.

I can already imagine the panicked reactions of those who are thinking about the impact on existing code. Rest assured, it’s about optional features, available only when strict typing is explicitly required. I also imagine that there will be those who claim that it is useless. This isn't completely true... The use of static variables allows the PHP compiler to perform optimizations which are unthinkable without first knowing the variable types. Besides, if you are looking for the best data structure, there is an excellent conference on the topic, presented by Patrick Allaert. So, what's the latest surrounding data types?

In reality, there are two novelties: “scalar type declarations” and “return type declarations”. The first one has to do with the definition of the expected type in the arguments of a function. If the expected value of the function is correctly formatted, an exception is returned by the language. For example, if you must define a function that divides two integers, you can now write it as seen below.



The feature “return type declarations” is used to declare the expected output format of your function. As before, you will get an exception if the wrong value is returned by your function.
Code :


Static typing purists say that the ability to provide an entire string of characters should return an error and may be disappointed by these new features… But, again, PHP 7 allows the developer to determine how strict it can be. Consequently, by adding the line “declare(strict_types=1) ;” at the beginning of the file, PHP will return an exception in this case as well. This works well for typing the return of a function as well as its arguments.

Code :


As these new features allow the compiler to optimize how the language runs, it seems like a shame to miss out. Of course, there is no need to rewrite all your code to switch to Version 7 as dynamic typing is still part of this release and there are still some cases where it comes in handy.

I forgot: PHP 7 now supports Unicode characters within strings. Inherited from the aborted PHP 6 project, this new feature brings PHP into the era of little 🐱.

CMS and Frameworks: who is now ready?

A lot of developers make use of a CMSs or frameworks, allowing them to concentrate on job-oriented tasks. In order to migrate towards PHP 7 and take advantage of the new innovations described, developers will have to wait for these frameworks to be updated. There shouldn't be any delays because PHP 7 won't introduce any new features other than those included in the beta version released in early July and developed by the teams that maintain CMS and Frameworks.

Some teams have even already announced they’re ready to move to PHP 7! Among them is the Symfony team, ready since August for versions 2.3, 2.6, 2.7 and the future 3.0, the Zend Framework, ready since version 2.4+, and the WordPress team, compatible since the release of version 4.3 in August.

The others are in the starting blocks:
• Drupal will integrate PHP 7 support in version 8, which is due for an imminent release (Drupal Second Release Candidate is now available).
• Joomla doesn't support PHP 7 at all in its current version (thanks to the String class
), but version 3.5 will be compatible.
• PrestaShop has not announced anything about PHP7 support but version, the fourth release candidate, has recently been made available and installs correctly with PHP 7. >> PrestaShop is now available (

The year 2015 is probably a turning point for the PHP language, since the performance gains made with version 7 allow it to compete with many languages in the speed category. PHP 7 also integrates the features that many developers have been waiting for. But, contrary to migrating from PHP 4 to PHP 5, breaks in the language don't have such a big impact and it isn't necessary to review your applications from A to Z in order to migrate. So, maybe it’s already time to consider doing your migrations…