Why Drupal 8 is defaulting its testing to PHP7 and why you should, too

Drupal 8 the newest version of the Drupal content management system is around the corner and will be released Nov 19. PHP7 - the newest generation of the PHP language powering Drupal - will be released later in 2015.

PHP7 features lots of new things, but the most significant part is a 20-50% speed increase, which comes from the completely rebuilt Zend engine VM that powers PHP under-the-hood.

The new code is not only easier to understand, but also cleaner, faster and doing much less memory copying.

However as with all bleeding-edge software there are bugs and sometimes those bugs can be so tricky that during normal development they do not occur. In fact the bugs Drupal 8 found pushed the release date of PHP 7 back - http://news.php.net/php.internals/89102 - but more to that later in this post. So when should you switch?

Drupal 8 already early on had a plan to support PHP7 out of the box with Drupal 8. (https://www.drupal.org/node/2454439).

During that effort by several Drupal 8 contributors, bugs and segfaults have been reported to the PHP team (bugs.php.net) and also incompatibilities have been resolved in the Drupal 8 and Symfony 2 code bases.

For example Null, False, True, which had been classes in Symfony 2, are now reserved keywords. Or Drupal 8 used the String namespace, which also now is reserved. Also Drupal 8 had been relying on uasort behavior being deterministic (which it is not) - though some cases still remain: https://www.drupal.org/node/2466097.

In the end Drupal 8's test suite did almost pass on PHP7, but there were some remaining test failures. Drupal’s tests run on DrupalCI, which is hosted and fully integrated into Drupal.org itself, supporting PHP 5.3-7, MySQL, sqlite and PostgreSQL for both Drupal 7 and Drupal 8 core and contrib modules. As the core maintainers wanted Drupal 8 to ship with full PHP7 support and no known bugs and, because PHP7 stable release was one week before Drupal 8's release now was the last chance to fix that. So the issue became critical again.

With the help of a 10 hour Drupal 8 Accelerate grant (thank you very much Drupal Association), neclimdul, me (Fabianx) and alexpott embarked  on a journey to track down and fix the remaining really really tricky test failures. (https://www.drupal.org/node/2603152, https://bugs.php.net/bug.php?id=70805 and https://bugs.php.net/bug.php?id=70808)

They succeed after close collaboration with the PHP internals team with me (Fabianx) providing the core developers with an EC2 instance, where the bug was easily reproducible and such the PHP internals team finally tracked down the bug in the garbage collector. I reported another bug with a script to reproduce ("array_merge_recursive corrupts memory of unset items") and it was fixed within 3-5 hours after posting the bug report(!).

And such PHP7 became green on Drupal CI on Oct 30, 2015 (https://www.drupal.org/pift-ci-job/73342).

Now with it being green an incentive was started to make PHP7 the default test environment (https://www.drupal.org/node/2607222).

This incentive lead to also testing Postgres and SQLite (and those environments are now available for testing) and while SQLlite passed (yeah), postgres failed with several strange bugs.

I followed up again with the PHP team, created two bug reports (https://bugs.php.net/bug.php?id=70861, https://bugs.php.net/bug.php?id=70862) and a pull request (https://github.com/php/php-src/pull/1619), which solved many of the issues and led to overall more stable PHP7 code base as it was a weird edge case (again!).

One issue is as of this time still remaining with postgres (https://bugs.php.net/bug.php?id=70866), but I am pretty sure that the awesome PHP team will track this one down, too. (Even though Drupal CI passes now, it still fails on my test machine.)

However as we still branch test Postgres with PHP 5.5 daily and that is stable, this will only affect a minority of the users and does not affect our ability to switch to PHP7 for general patch testing (with MySQL 5.5). As of now Drupal 8 has 100% test passes with PHP 7 and MySQL, PostgreSQL and SQlite (https://www.drupal.org/node/3060/qa).

Switching to PHP7 for patch testing will allow to reduce patch test time by around 30% (from 30 min to 21 min) and it will allow us to find potential regressions early. This should reduce the costs of the testing infrastructure to the Drupal Association significantly.

Lessons learned

• Drupal 8 and PHP7 is an open-source community collaboration success story with close collaboration of PHP with Drupal 8 and Drupal 8 with Symfony.

• Drupal 8 was able to find many many strange bugs with its very extensive test suite and being a complex application itself. That made PHP7 more stable for everyone, as well as finding Symfony/PHP7 incompatibilities earlier than they might otherwise have been discovered

• Being able to run Drupal 8 on PHP7 directly and know that it will work is a huge benefit to Drupal 8 itself. In fact I also switched over my own Drupal 8 development environment now to PHP7, which means I can test my code faster.

• Running and switching your test suite to PHP7 not only will give you confidence that your application is well supported on the newest PHP version, but it will also give you beneficial speed improvements.

• All of this means that Drupal 8 and PHP 7 will be viable for production more or less as soon as they reach stable releases, so that real sites can take advantage of the ~30% performance improvement relative to PHP 5.6.