Matt Glaman has written up a post for his site showing how you can write better Drupal code using PHPStan, the PHP static analysis tool.

PHP is a loosely typed interpreted language. That means we cannot compile our scripts and find possible execution errors without doing explicit inspections of our code. It also means we need to rely on conditional type checking or using phpDoc comments to tell other devs or IDE what kind of value to expect. Really there is no way to assess the quality of the code or discover possible bugs without thorough test coverage and regular review.

If you use PhpStorm, you will notice all of their helpers which analyze your code and add static analysis. [...] That's awesome. It's pretty amazing that PhpStorm and a few plugins can give us some stability in our PHP code.

While the functionality in PhpStorm is useful, there are some pitfalls including the fact that everyone would have to use PhpStorm. He makes the suggestion that PHPStan can effectively replace these helpers and, with a bit of customization, provide just as much quality control for your Drupal code. He links over to a custom PHPStan extension for Drupal and an example YAML configuration. He also includes helpful tips around bootstrapping the autoloader, return typing and changes it provides for using the entity manager.

Matt Glaman has a new post to his site where he walks you through the setup and execution of Drupal's unit tests in the DDEV platform (a Docker-based project that makes it easy to get an environment up quickly).

DDEV is a local development stack built on top of Docker. It gives you all of your environment needs without messy configured on your host machine, without needing to know Docker or configure your own containers. Which is great, and makes life easier. Instead of just using DDEV to develop your site or application locally, why not also run your tests within it?

I have had quite a few people ask me how I configure my setup for testing with Drupal’s PHPUnit test suites. [...] All of these are the same reasons for using a virtual machine or containerized local development stack. So, it is fitting we run our tests within these local stacks as well!

In this article, part one of three, he assumes you already have a DDEV environment up and running with a Drupal application running inside (there's a guide here). With that in place, he shows how to configure PHPUnit via the phpunit.xml file, changing the "SIMPLETEST_*" values for the localhost and local DB connections. He shows how to run the tests by SSHing into the web Docker container and pointing PHPUnit at the configuration file. The end result should look something like this in a terminal.

On the Checkpoint Research blog there's a recent post covering the recent critical Drupal bug, a.k.a. Drupalgeddon 2, and providing a deeper look into the bug and how the exploit worked.

Two weeks ago, a highly critical (21/25 NIST rank) vulnerability, nicknamed Drupalgeddon 2 (SA-CORE-2018-002 / CVE-2018-7600), was disclosed by the Drupal security team. This vulnerability allowed an unauthenticated attacker to perform remote code execution on default or common Drupal installations.

[...] Until now details of the vulnerability were not available to the public, however, Check Point Research can now expand upon this vulnerability and reveal exactly how it works.

The post covers the basic issue, a lack of input sanitization on Form API requests, and what versions it existed in. It then dives into the technical details, showing a proof of concept for the exploit and how an attacker might locate a place in the application to use it. It also looks behind the scenes at the code that handles the request and shows where the issue lies. The post ends with a look at "weaponizing" the exploit and executing whatever code you'd like on the server.

The Drupal project has announced a critical security vulnerability in the currently supported versions of the popular CMS: Drupal 7 and 8 (as well as v6). The announcement on the main Drupal site details the issues and provides a link to an FAQ with more detail about the issue.

A remote code execution vulnerability exists within multiple subsystems of Drupal 7.x and 8.x. This potentially allows attackers to exploit multiple attack vectors on a Drupal site, which could result in the site being completely compromised.

[...] Drupal 8, 7, and 6 sites are affected. According to the Drupal project usage information this represents over one million sites or about 9% of sites that are running a known CMS according to Builtwith.

The issue could allow an attacker to take full control of the application and execute whatever code they'd want to on the server. They recommend upgrading immediately to safeguard your Drupal application. They also provide links to a guide on what to do if you are hacked and to the Drupal 6 patch (as well as steps you can take if you can't upgrade).

Michelle Sanver has written up a qucik post on the Liip blog sharing a few things she thinks we can all learn from the Drupal community.

I started hearing about Drupal 8 back in 2014, how this CMS would start using Symfony components, an idea I as a PHP and Symfony developer found very cool.

That is when I got involved with Drupal, not the CMS, but the community.

I got invited to my first DrupalCon back in 2015. That was the biggest conference I have ever been to, thousands of people were there. When I entered the conference building I saw several things, one of them was that the code of conduct was very visible and printed. I also got a t-shirt that fit me really well – A rarity at most tech conferences I go to. The gender and racial diversity also seemed fairly high, I immediately felt comfortable and like I belonged – Super cool first impression.

She goes on to talk about more of her experiences at the conference, both in how it was run and about her fellow attendees. She ultimately shares the main message of the post:

[...] Embrace our differences, and each other, and accept that we do different things and we are different people and it doesn’t matter because that is what makes community work, that is what makes us awesome. Diversity matters, Drupal got this.

On the php[architect] site there's a new tutorial posted from Oscar Merida about testing Drupal sites with Behat, a popular PHP-based "Behavior Driven Development" testing tool to help ensure your application is performing correctly from the outside.

If automated testing is not already part of your development workflow, then it’s time to get started. Testing helps reduce uncertainty by ensuring that new features you add to your application do not break older features. Having confidence that your not breaking existing functionality reduces time spent hunting bugs or getting reports from clients by catching them earlier.

Unfortunately, testing still does not get the time and attention it needs when you’re under pressure to make a deadline or release a feature your clients have been asking for. [...] After reading all the theory, I only recently took the plunge myself. In this post, I’ll show you how to use Behat to test that your Drupal site is working properly.

He starts by listing some of the requirements you'll need to get started (packages installed via Composer) including the installation of a Drupal specific plugin to make testing these sites easier. From there he shows how to configure the Behat tool and write a simple feature to test the visiting of a certain page and looking for matching results. He also includes tips about testing with user authentication, using custom contexts and Selenium integration.

php[architect] magazine has released their latest issue for April 2016 - Off the Island: Drupal:

I’m excited to see the Drupal and PHP communities building bridges to collaborate (“Getting off the island” as Larry Garfield likes to say) and also learn from each other. This month, we’ll look at how the Drupal project has embraced tools and techniques like object-oriented programming and Composer.

This month's edition includes articles about:

• Drupal 8 Module Development
• Composer and Drupal 8
• Drupal Security & Vulnerability Management (this month's free article)
• Generating documentation from source code

As usual, the regular columns have come back for another edition - Community Corner, Security Corner, Education Station and Leveling Up. You can get a copy of this issue for your very own directly from the php[architect] site or pick up a yearly subscription while you're there.

As is mentioned in this new post on the Symfony Finland site, the functionality allowing the Twig templating engine to perform Angular 2 Universal Rendering.

Angular is a household name when it comes to JavaScript frameworks. They've been going through a major transition since the announcement of Angular 2. In the latest development Angular 2 will be getting PHP / Twig support for isomorphic rendering.

[...] So the Angular and the Drupal development teams have started working together to bring Universal Rendering to PHP and Twig. The details remain murky on how exactly this will be implemented (using a Node.js server or a PHP library), but a PHP library (not an extension written in C) would be the easiest option for developers.

He points out that there's also a chance that the result could be coupled to Drupal (at least at first) but hopes are that it will end up as a generic component usable in any system using Twig. The post also includes links where you can find out more information about the topic of "Isomorphic Rendering" too.

The Sound of Symfony podcast has come back and posted their latest episode with hosts Magnus Nordlander and Tobias Nyholm. In this latest episode (#11) they talk about Symfony 4 and look forward to some of the things they'd like to see in this future release.

Having recovered from SymfonyCon and had happy holidays, Sound of Symfony is back on the ether(net). This week we talk about what we'd like to see in upcoming versions of PHP and Symfony.

Other topics mentioned include:

• Various Drupal initiatives
• Sub-requests (a request to render just a partial page, not the whole thing through the HttpKernel)
• Object-oriented CSS

You can listen to this latest episode either through the in-page audio player or by downloading the audio directly. If you enjoy the episode be sure to subscribe on iTunes to get the latest episodes as they're released.

On the Kinsta blog Mark Gavalda has shared their latest PHP 7 versus HHVM benchmarks now that the first official stable release of PHP 7 has been unleashed for public consumption. They opted for testing with a large variety of tools and software rather than simple benchmarking scripts to give a more "real world" look at the difference between the two.

To see how much of an improvement we can expect from this new PHP interpreter we put the public release version of PHP 7.0 to test and compared a couple of popular software suites’ performance using PHP 5.6.16, PHP 7.0 and HHVM 3.10.1 on a bare metal server (so virtualization doesn’t interfere with the results). Tested software includes WordPress 4.3.1, Drupal 8, Magento 2.0 CE, OctoberCMS build 309, PyroCMS v3 beta2, and Flarum v0.1.0-beta.4.

The basic tl;dr of the post is that HHVM still performs better for all of the software tested but PHP 7 is not too far off on some of them. They share the specifications of the machine (bare metal) they used for testing and get into the results for each of the seven pieces of software tested. Their results are in transactions per second and both graphed and numeric results are shown. Unfortunately, though, the Flarum software had to be kept on a "pending" list as it doesn't run on either PHP 7 or HHVM properly.