Phoronix has a new post to their blog sharing some benchmark results for PHP 7.3, the next major language release, and things are looking positive!

Released on Thursday was PHP 7.3 RC6 as the last planned pre-release for the upcoming PHP 7.3. Here are some benchmarks looking at the PHP 7.3 performance compared to PHP releases going back to the v5.5 series on a Linux server.

[...] I ran some fresh benchmarks over the past day on PHP 5.5.38, PHP 5.6.38, PHP 7.0.32, PHP 7.1.24, PHP 7.2.12, and the PHP 7.3.0-RC6 test release. [...] PHP 7.3 is just shy of 10% faster than PHP 7.2 in the popular PHPBench. PHP 7.3 is 31% faster than PHP 7.0 or nearly 3x the speed of PHP5.

The post includes more benchmarks that reinforce this same trend with both the Zend performance testing and their own testing framework.

Overall, PHP 7.3 is shaping up to be another notable upgrade to the PHP7 series for its continued performance improvements, the new PHP FFI interface, and other new additions for this PHP release due out in early December.

On the main PHP.net site, they've posted the announcement of the release of the latest Release Candidate for the upcoming PHP 7.3.0 version: PHP 7.3.0.RC2.

The PHP team is glad to announce the next PHP 7.3.0 pre-release, PHP 7.3.0RC2. The rough outline of the PHP 7.3 release cycle is specified in the PHP Wiki.

[...] For more information on the new features and other changes, you can read the NEWS file, or the UPGRADING file for a complete list of upgrading notes. Internal changes are listed in the UPGRADING.INTERNALS file. These files can also be found in the release archive.

As with other preview releases you can download this version from the QA site for source packages and the Windows QA site for the Windows binaries.

TJ Miller has written up a post for his site sharing a method he's created to verify the compatibility of a package in Laravel based on the version of Laravel installed.

I’ve been working with Honeybadger to build a new set of PHP integrations. I would like to write more about that soon, however, I feel like I’ve stumbled across something that could be useful to others. I wanted to share it as soon as I could.

For the Laravel package, I was aiming for Laravel 5.5 and newer support as it is the latest LTS version. [...] In hindsight, I don’t think that I actually ever tested it against a 5.5 install. I relied on the CI process to make those verifications for me.

[...] As Laravel 5.7 is now out, I needed to add support to both the package’s composer configuration and verification in CI. [...] Now that I am supporting three versions I felt that I needed a more specific way of verifying compatibility with different versions of Laravel.

He shares his initial version of his Travis-CI configuration, running tests on PHP 7.1 and 7.2 with the prefer-lowest flag. In order to make it easier, he updated this based on what he'd seen in other packages: adding a matrix that runs PHP 7.1 through 7.3 against versions 5.5.x, 5.6.x and 5.7.x to ensure compatibility across all variations. His resulting build looks something like this.

In a quick post to the Laravel News site they mention another new feature coming in the v5.7 release of the framework: the addition of the dump server for debugging output.

At Laracon US 2018 Taylor Otwell announced that Laravel Dump Server would come packaged with Laravel in version 5.7! It will be a development dependency in laravel/laravel composer file.

Starting in Laravel 5.7 you’ll get this command out-of-the-box that allows you to dump data to the console or an HTML file instead of to the browser.

The post outlines what the "dump server" provides and provides an example of the command used to start it up. You can find out more about the dump server in this previous article.

Colin O'Dell has shared an interesting setup he's created to make it easier to switch between PHP versions when testing your code. In his latest post he shows how to switch the version "on cd" (directory change) with the help of some command line shell tooling.

After using phpbrew to manage my local PHP versions for a while, I got tired of re-compiling PHP after every release and decided to install multiple PHP versions side-by-side with Ond?ej Surý's PPA. One of the features I missed from phpbrew was the ability to run a command like phpbrew use php-7.2.8 to automatically change the php command to that version, so I ended up implementing this feature myself using symlinks and shell aliases.

He then walks through his end result, showing the modification of the default php symlink and aliases that can be used to dynamically switch its target. He then includes some examples of how to automate this using your application's PHP version requirements in the composer.json and a simple ZSH script that's triggered on directory change.

Jordi Boggiano, lead developer on the Composer project, has posted another of his PHP version statistics posts, this time for the first part of 2018.

It's stats o'clock! See 2014, 2015, 2016.1, 2016.2, 2017.2 for previous similar posts.

A quick note on methodology, because all these stats are imperfect as they just sample some subset of the PHP user base. I look in the <a href="https://packagist.org/>packagist.org logs of the last month for Composer installs done by someone. Composer sends the PHP version it is running with in its User-Agent header, so I can use that to see which PHP versions people are using Composer with.

The remainder of the post shares some of the results and differences since November 2017. Among the highlights are:

• The use of PHP 7.2 has increased by a large percent
• The use of all over versions (including PHP 7.1) is dropping
• There is still a large number of packages that only require a version in the PHP 5.x range to be installed

Check out the full post for the complete stats on versions in use and trends (along with some nice graphs of the results).

On the Delicious Brains site they have a new post that makes a suggestion to the WordPress plugin developers out there: stop supporting legacy versions of your plugins and move on.

I recently saw this tweet from Danny van Kooten which reminded me of one of the many major gripes developers have with WordPress – supporting ancient PHP versions:

"STOP SUPPORTING PHP 5.2 IN YOUR NEW PROJECTS. No one using it is actively installing plugins, trust me."

Yes, (unbelievably) WordPress still supports installations of PHP 5.2.4! As plugin developers, we can’t change that over night but we have the power to stop supporting these legacy versions in our plugins where we have control over the codebase.

He talks about how, despite the fact that the WordPress project itself strives for ultimate backwards compatibility, it's just not run on older versions of PHP as much. They share some statistics about the number of WordPress installs on each version of PHP starting with v5.2. The results show that the overwhelming majority are on v5.6 with a split between <=5.3 and >=7.0 for the remainder. They also share some statistics from their own plugins finding that the >=7.0 takes the lead.

The post then shares some of the reasons for making the upgrade to only support newer versions of the language including security updates, speed and developer experience. It finishes up with some of the steps to follow to inform users of the intent to deprecate old support and when to make the move.

The main PHP.net site has posted the announcement(s) of the release of updates for the three supported versions of the language: 7.1.15, 5.6.34 & 7.2.3.

The PHP development team announces the immediate availability of PHP 7.1.15, 5.6.34 and 7.2.3. This is a security fix release, containing one security fix and many bug fixes. All [PHP] users are encouraged to upgrade to this version.

Fixes include changes to the DateTime handling, LDAP connectivity, Phar construction, PostgreSQL issues and changes to the SPL. You can get these latest versions either from the main downloads page or on windows.php.net for the Windows binaries.

On thePHP.cc site there's a post that talks about an upcoming PHP release, PHP 7.2, and why it's important despite it not having any amazing new features or too much in the way of major changes. There are a few things they mention, however, that make it seem a lot less boring.

A while ago, Sebastian said in a presentation that "PHP 7.2 will be a boring release". What he meant by that is that PHP 7.2 does not have an awful lot of fancy new features. Okay, adding the sodium extension to PHP's standard distribution is great, but the majority of PHP developers do not have to deal with cryptography in PHP on a daily basis.

[...] We are not so sure anymore that PHP 7.2 really is a boring release. As with every release in the 7 series, PHP keeps getting faster and faster. [...] The PHP core developers, again, did a great job cleaning up some more sins of the past. [...] Along with the cleanups that were already done, quite a few things have been deprecated in PHP 7.2, which schedules them for removal in PHP 8.

They talk about some of the changes coming with PHP 7.2 including the addition of libsodium support, smaller changes to variable handling and what's being done to prepare the language for the next major version, PHP 8. They also remind their readers that no version of PHP 5 - even 5.6 - is supported any longer (just security fixes now) and all current users of the language should upgrade to PHP 7.0+ immediately.

The HHVM project has made an announcement on their site about the latest update for the PHP language processor, v3.24 and how, among the list of changes, they're completely dropping support for PHP 5.

HHVM 3.24 is released! This release contains new features, bug fixes, performance improvements, and supporting work for future improvements. [...] 3.24 is the final release targeting PHP5; this includes source-level compatibility for PHP5 extensions (ext_zend_compat). We recommend migrating to Hack or PHP7.

As 3.24 is supported though 2018-12-17, this means that support will end at roughly the same time as PHP5 itself is scheduled to become unsupported (2018-12-31).

Other updates in the release include the retiring of support for Debian 7 Wheezy and Ubuntu 17.04 Zesty, the inclusion of "using" blocks and the addition of the XHP Attribute Spread Operator. You can find out complete details about this release from the HHVM blog.