PHP 7.0 or 7.1 or 7.2?

Submitted by peter on Sat, 02/24/2018 - 07:12

PHP 7.2 is now ready to replace PHP 7.1 which in turn replaced PHP 7.0 as the current version of PHP. Is the change worth a manual upgrade before PHP 7.1 or 7.2 migrates to your operating system? The short answer is no.

The upgrade on your local development machine will be worth the effort if you are exporting code to a server that is already upgraded. In every other situation, wait for PHP 7.1 or 7.2 to appear on all your machines and all your customer's machines before committing to code that will only work on later releases.

The one real improvement is encryption, something you want to tackle separate to all the other code changes.

Execution speed

PHP 7 is a huge speed improvement over PHP 5. PHP 7.1 execution speed is mostly identical with PHP 7.0 for identical code and PHP 7.2 is just a slight improvement on 7.1. There are small performance improvements for some code but not enough overall improvement to justify the work. For performance improvements, the upgrade from PHP 7.0 to 7.1 or 7.2 is not in the top 50 improvements you could make.

There are some code differences that could make your 7.1 code slightly faster if you go through all the code. That is a lot of work. I suggest you maintain PHP 7.0 compatibility until everyone is on 7.1 then make the code changes for clarity, not performance.

PHP 7.2 offers a performance improvement if you replace all uses of each() with foreach(). I scanned the code from an open source project. Most uses of each() are in Javascript, not PHP. The few uses of each() are really bad code that should be replaced for clarity and precision, instead of using an accidental effect of each().


You often have no control over encryption because you use the encryption on messages shared with someone else. You cannot improve the encryption until the sender or recipient changes. Changing encryption on an existing file can create the problem of taking down a system for a long time while recreating your encryption. If you can change your encryption, PHP 7.2 offers a big improvement on encryption.

Think about the code change. A mistake in encryption could expose all your data. You want to make all your code changes perfect then test extensively. The best approach is to leave your current encryption in place until every other code change is finished and proven through extended testing. You then have the testing base to prove encryption changes work.

Do one change at a time and test your testing before ripping into encryption. Test, test, test.

You can also use the change to go to one of the higher levels of the new encryption which might require more processing power. Encryption often uses more processing when you increase key size. Make your key size double what your competitors use. Invest in the extra CPU power. You will then survive the next round of attacks when your competitors fall.

Code changes

There are a few code changes to make when every one of your projects and servers is updated. Most are for clarity only and do not change the way your code works. I mention here only changes that have a useful impact.


Think of the following code as standard PHP 5/7 code using PHP 7 syntax. The code uses a foreach() to loop through an array.

$array = [['a', 3, 'y'], ['b', 6, 'x']];
foreach ($array as $entry)
    list($name, $size, $type) = $entry;
    echo $name, $size, $type;

PHP 7.1 lets you use the following simpler syntax. The execution speed might improve because there is one less function.

$array = [['a', 3, 'y'], ['b', 6, 'x']];
foreach ($array as [$name, $size, $type])
    echo $name, $size, $type;

Class constants

PHP 7.1 adds visibility settings to constants defined in classes. You can use the following code.

class test
    protected const SOMETHING = 3;

I rarely use constants because they are rarely constant. If you have a constant in a class and want it to be private, the first question would be why it is not provided from a central configuration list.

Multi catch Exception handling

The catch() function can now catch multiple exceptions.

    // ??
catch (exception1 |exception2 $e)
    // ??

Negative string offsets

When you specify a string, you can add a negative offset. There are many examples of this feature and some are hard to understand easily when looking at a large chunk of code. I suggest you code for clarity instead of using this option all the different ways you see online.

The following code displays the last two characters of $string and has the overhead of function substr().

$string = 'uktyt55fgjt';
echo substr($string, -2);

The following code displays the last two characters of $string using the PHP 7.1 syntax and might be slightly faster.

$string = 'uktyt55fgjt';
echo $string[-2];

Things to remove

Some things will disappear in PHP 7.2 and need to be cleaned out in PHP 7.1. PHP 7.2 will drop some more old stuff. When changing code your 7.0 for 7.1, you can also clean out most of the code that will not work in 7.2.

Extension mcrypt

Mcrypt is not safe. Use something else. There is a warning in PHP 7.1 and mcrypt will not be in PHP 7.2. You can replace mcrypt without waiting for PHP 7.1. If you can jump straight to PHP 7.2, there is an excellent replacement for mcrypt.


Some options in mb_ereg_replace() and mb_eregi_replace() get a warning in PHP 7.1 and disappear in PHP 7.2.


PHP 7.1 is a minor improvement on PHP 7.0 and not worth any special effort to push into your computer ahead of the normal upgrade cycle for your operating system. Replacing mcrypt is something you can do now and should do now without waiting for PHP 7.1. PHP 7.2 has a far better encryption default and worth the jump from 7.0 to 7.2 if you use encryption.