On the Exakat blog there's a new post covering some of the impact that PHP versions have on codebases they've reviewed in the normal course of their product's analysis and the requirements of Open Source software.

With the upcoming PHP 7.3, the question of the next migration is back on our tables. We’ll hear a strange mix of begging to move to the new versions for features and security, mixed with a constant threatening that some old versions will soon be unmaintained or worse. Indeed, there is versions impact on PHP code bases.

Particular witnesses of that evolution are open source projects. They usually have to support a wide range of versions, and in the same time, are actively encouraged to use the newest features. It is a delicate work of balancing compatibility and progress.

To observe the way Open Source projects handle the evolution of PHP, we have audited 1977 Open source PHP projects, by linting them with PHP versions from 5.5 to 7.3. This taught us the impact of PHP on code, over a long period of coding. Let’s review them.

The post starts by talking about linting of PHP files (checking the syntax for issues but not executing the contents). It then shares some statistics about the number of Open Source projects that lint on every build and how it has trended over time. They also share some results on the age of packages that are in wide use, showing that the ration of "old code" to "young code" is surprisingly similar.

With the final release of PHP 7.2 coming on the horizon the Exakat blog wants to be sure you and your code are prepared for some of the changes. In this new post they share things to change and improvements to expect in this latest version of the PHP language.

PHP 7.2 is around the corner, and shall be out soon, thanks to the hard work of @RemiCollet), Sara Golemon (@saramg) and countless others that run tests and submit bug reports. PHP 7.2 is already RC6, and the documentation has even been updated : it is high time to get ready for PHP 7.2.

We have been hard at work, at @Exakat, to prepare the migration analysis. This is our take on this upcoming task.

He's broken the changes coming down into a few categories based on the actions required and what you can do to prepare: Know, Lint, Static (Analysis), Unit testing and Logging. A chart is then included showing each of the changes, which category they fall into and links to more information about them and what has been updated (or added).

In this post over on Medium.com Ond?ej Mirtes looks at what he calls the "Three Pillars of Static Analysis in PHP" - three kinds of testing you can do to catch errors "at rest" in your codebase.

My credo is that everything that can be automated should be automated. Computers are really good at repeating tedious tasks and they don’t usually make mistakes while us squishy humans are defined by making mistakes everywhere we go.

[...] In the following article, I’d like to introduce three tools that will help you to find errors and inconsistencies in your codebase. If your build integrating these tools finishes successfully, you can be pretty sure your application is in a good shape.

His list of three tools covers checking for:

• syntax errors using PHP-Parallel-Lint
• PHP_CodeSniffer "sniffs" to ensure code consistency
• using PHPStan to check for more complex bugs and issues than the other two

He covers some of the things the last option verifies and links to another introductory article about the tool to help you get started.

In a new post to the ServerGrove blog they look at linting tools for various circumstances including standard PHP, Twig templates and Composer configuration.

Today’s projects are built up from dozens of different components, configuration files, third-party libraries, tests, build scripts, etc. And even if you have the greatest test suite, bad things can happen sometimes. It’s important to catch bugs as early as possible, and syntax validators can be a great (and easy) addition to your continuous integration system. You would be surprised at how many problems are caused by syntax errors. At ServerGrove, we see these kind of problems with our clients almost every day.

Their list shows you how to lint (syntax check) several different types of content:

• standard PHP code
• Twig templates
• Composer configuration
• XML files
• Bash scripts
• JSON files
• YAML files

Some of them use tools that already come built-in (like PHP's "-l" or Twig's "twig:lint") but others require the use of external software such as xmllint or melody. Command examples are also included for each.

If you're a git user (you do use git, right?), there's a powerful feature that can help perform some automatic actions in your repositories - git hooks. In this new post to the SitePoint PHP blog, Timothy Boronczyk introduces you to them and how to set them up.

When certain commands are run, Git searches the .git/hooks directory for suitable hook scripts which are then executed if found. You’ll find a small set of example scripts there (you can activate them by renaming them to remove the .sample prefix and setting their executable bit), and a complete list of hooks can be found in the githooks(5) man page. This article suggests a handful of hooks which can streamline development and help improve your efficiency.

He gives four different examples of checks based on the state of the commit (like pre-commit or post-commit):

• Lint Checks
• Spell-Check Commit Messages
• Checking Standards
• Automatically Run Composer

Each comes with the example code needed to implement them and some description about what they're doing.

Michelangelo van Dam has started a new series of posts on his blog about quality assurance in PHP projects with this introduction and a look at the first tool on his list PHPLint.

Quality Assurance has become an increasing important part of web application development, especially with PHP applications. [...] Luckily there are a lot of tools available that allows you to increase quality of these web applications, and the best part is they are all based on PHP! Let's have a quick look at what tools are interesting to start improving quality assurance on your PHP projects.

The first tool, PHPLint, helps you validate code against syntax errors and is built into the command-line PHP you already have. He describes its use, both on the command-line and in a pre-commit hook on his git repository

For more PHP QA-related information, he also points out the book from Sebastian Bergmann and Stefan Priebsch as a good reference too.

On the Content with Style blog, there's a "quickie" you can drop into a subversion hook as a part of your check-in that will run the lint command on only the changed files (not your entire repository).

If you haven't done it in a hook already, here's the quick way to check all your changed files for syntax errors.

This sort of command would be the most useful in a pre-commit hook to ensure that everything passes correctly. Their example only looks for ".php" files, but can be modified easily if you happen to use ".html" or another custom extension for your pages too.

Stoyan Stefanov posts about some handy PHP development tools that he's added to his TextPad software and wanted to share with the community.

There's four tools in the list (links off of his Tools menu):

• PHP lint (a.k.a. syntax check)
• PHP help
• PHP Manual
• JS Lint

On ones like the PHP manual, it's really a link to a browser that opens the right page on the PHP.net website.

Stoyan Stefanov posts about some handy PHP development tools that he's added to his TextPad software and wanted to share with the community.

There's four tools in the list (links off of his Tools menu):

• PHP lint (a.k.a. syntax check)
• PHP help
• PHP Manual
• JS Lint

On ones like the PHP manual, it's really a link to a browser that opens the right page on the PHP.net website.