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.

In a new post to his site Tomas Votruba walks you through the process he followed for moving his site [away from the Jekyll static site generator over to Statie], PHP-based static site generator.

Jekyll is great to start for micro websites like gomonorepo.org and <a href="https://gophp71.org/>gophp71.org from Jekyll to Statie. Can new init command make this piece of cake? And what needs to be done next?

He goes through each step of the process (nine of them), providing code and configuration examples along the way:

• Create Basic Statie Structure
• Move Source files to /source Directory
• Move Parameters Files Under parameters > [param name] Sections
• Upgrade Absolute Links to Moved Files
• Load Moved YAML Files in statie.yml
• Remove site.data. and use Variables Directly
• Setup Github Pages deploy in Travis
• Clean Metadata from Headers

The final step in the process are the commands to run the project locally and ensure that everything it working as expected before deployment.

On the Contentful blog they've posted the second part of their series reviewing static site generators for PHP. In this new article they look at Jigsaw, a Laravel-based tool.

In the first article of the series we took a look at Sculpin, the PHP static site generator which is currently the most starred on Github. Today we’re exploring Jigsaw, a tool which promises to bring a Laravel-based approach to the world of PHP static site generators (SSGs).

The author starts by sharing some about his (somewhat limited) experience with Laravel. From there he dives right in, showing the creation of a new Jigsaw site including configuration and how to serve it up locally. It then gets into detail about the directory structure of the site, asset handling and adding new content. The post ends by answering the "is it ready" question for their own needs (at Contentful).

The PHP Roundtable podcast, hosted by PHP community member Sammy Powers, has posted their latest episode: #73 - PHP Static Analysis. In this episode Sammy is joined by Ond?ej Mirtes, Craig Duncan, Vladimir Reznichenko and Damien Seguy.

Static analysis is a fancy word to describe a tool that looks at our code and gives us helpful hints on how to improve it. We'll be discussing what static analyzers do, which tools the PHP community has access to, and how we can incorporate the tools into our daily development flow.

You can catch this latest episode in a few different ways: either using the in-page audio or video player, by downloading the audio file directly or by watching the recording over on Youtube. If you enjoy the show, be sure to subscribe to their feed and follow them on Twitter for updates when new shows are released.

On the Exakat blog there's a new post sharing five uses of the "static" keyword in PHP applications. This includes the less common static closures and static class names.

Static is a PHP keyword with many usages. It is almost universally used, though there are many variations of it. Let’s review all the five of them :

• static method
• static property
• static closure
• static variable
• static as a classname

The post goes through each of the items in the list giving a brief explanation of how it's used and a code example showing it in action. The post finishes with some tips on evaluating your own code for the use of "static" and tips for each to make your code easier to wrangle and maintain in the future.

In a new post to his site Matthias Noback walks you down a road to dependency injection, sharing his process of migrating a codebase from static calls to a more modern, robust dependency injection pattern.

I've worked with several code bases that were littered with calls to Zend_Registry::get(), sfContext::getInstance(), etc. to fetch a dependency when needed. I'm a little afraid to mention façades here, but they also belong in this list. The point of this article is not to bash a certain framework (they are all lovely), but to show how to get rid of these "centralized dependency managers" when you need to.

He talks about this common use case of "statics everywhere" and some of the problems with coupling your code to a static way of doing things. He walks through the steps towards modernization including injecting the container itself into the controller and shifting logic out into services. He also makes suggestions on what to do when constructor injection isn't possible and how to deal with "temporal coupling".

If you're a user of the Jigsaw static site generation tool from Tighten, Matt Stauffer has a new post to his site that could come in handy. He shows how to automatically create a sitemap.

There are a few tasks that are still pretty tough with static sites—for example, search, and submitting forms (which we're trying to fix with FieldGoal). But there are other tasks that are tough-but-possible, and key among them are RSS and sitemaps. Let's start with sitemaps.

There was a feature recently added to help with this allowing you to add extra "hooks" to fire when the site builds. Matt makes use of this (and this package) to create a GenerateSitemap class that goes through each item in the site and adds a link to the sitemap.xml file. He shares the code for this class and the updates to make to the configuration and bootstrapping to correctly load the class.

Tomas Vortuba has a new post to his site sharing some of his experiences with static function analysis (and fixing) and the trap he got himself into when evaluating the current state of his code. This is a continuation of his series covering the use of the SymfonyCodingStandard package.

PHP story with code examples, copy-cat killers, just a little bit of static, consistency, sniffs and way to prevent all that ever happening ever again.

In his post he uses an example "fixer" for testing DocBlock comments to see if they provide much useful information over what the PHP itself provides. He dives "under the surface" and looks at the steps it takes to accomplish this. He then gets to the "trap" part, showing the code behind the fixer and how depending on 3rd party packages and their parsing lead to code mistakenly being "fixed". He finishes up the post with a look at a few solutions that could help make these "traps" easier to fix including dependency injection and preventing the issue specifically with static functions.

The Laravel News site has posted a tutorial that takes you deeper with factories when using the framework looking at the factory states.

I suspect that if you are familiar with Laravel that you might use factories and possibly even factory states in your application development. The documentation shows you the mechanics of using factories to seed and create test data, but there are a couple of guiding thoughts to using factories with your models effectively that I’d like to consider.

He starts with two options he sees for using factory states: making them with static values or using them to make simple models instead. He goes through these two options, introducing some of the basic concepts of each, how it would work and the code to make it happen. He also covers a few other approaches including the use of a trait to include the factory functionality directly in a class. He finishes the post with a few links to more information in the Laravel manual and other outside resources/tools.

Mark Baker continues his series looking at the use of static properties and methods in applications and how to test them. In this second part of the series he focuses more on some of the unintentional side-effects that could happen when you're trying to refactor them out.

In the first article in this series, I wrote about the problems with testing static methods in classes, and showed a few approaches that allow us to write mocks for statics. Testing classes where we have static properties is a lot harder to manage, because any changes made in any test to those properties are global, across the entire test suite, not simply the test that we are running. Static properties are part of the global state, and we can’t simply tearDown() those changes in the way that we do with instances — at least we cannot easily do so if the property has a visibility of private or protected.

He goes through an example of a refactor from a static property (essentially in the global scope) to a private property. He points out the issue of setting a static value in what seem to be separate child classes, the fact that it actually changes the base value, not the individual ones, leading to potentially unintended consequences.

His main recommendation is to avoid the use of static properties all together. Where that's no possible (like in a legacy project) he offers two potential solutions: either replace them with constants if they're never changed or changing them to instance properties.