The SitePoint PHP blog has a quick tutorial posted helping you get your application PHP 7 ready with the help of the PhpCompatibility "sniffs" for the widely used PHP_CodeSniffer tool.

Sooner or later, there will come a time when you will need to migrate your projects to different PHP versions. How will you check if you’re compatible with a PHP version different to the one you’ve been developing on?

One possibility is always to install the version of PHP we want to migrate to, run php -l or something like PHPSA to check for syntax errors, check the PHP documentation for known issues with the migration and hope for the best. Or, we can use some available third party tools to check for PHP version compatibility in our projects.

The article then introduces the PHPCompatibility set of sniffs for PHP_CodeSniffer and installing them with a "git clone" in the right Standards directory. Also included are some basics for using PHP_CodeSniffer (like the command line options) and an example of some of the output from the compatibility check. The post wraps up with a real-life example using the PHPMailer codebase and testing it for PHP 5.6 readiness.

On the This Programming Thing blog there's a recent post showing you how to define your own "sniff" settings for the popular PHP_CodeSniffer tool. The codesniffer lets you define standards that need to be in place for all code in your application and notifies you of violations.

At Zimco, we’ve started working on standardizing our coding but we ran into a little problem while we tried to automate the process of making sure our code adhered to that standard. [...] I think we get into our own way of doing things and everything else is wrong. This code makes me feel irrationally angry (so angry I’m having a hard time not fixing it…). Ultimately, the best way to fix these kinds of formatting problems is to sit down and discuss what’s best and have everyone stick to the same set of standards.

They talk some about the place for PSR in coding standards (specifically PSR-2) and the fact that there's already "sniffs" provided to check against those rules. However, they point out that running this against a non-PSR-2 codebase can be a mess and show you how to customize your own standard to more match your current state. They use an XML configuration file to update the tab width setting to four spaces and then apply the PSR-2 standards. They also show how to exclude certain rules and mention a handy plugin you can use in Sublime Text to keep your code within standards.

Marcelo Gornstein has posted a new article showing how to use SWIG and libpcap to sniff packets from the network directly from his PHP application.

I've been wanting to try SWIG for a long time, but never got the chance, for one thing or the other. So this weekend I've finally decided to give it a try by trying to create a php extension that access a small C++ wrapper for libpcap, so I can sniff packets directly from PHP. Just for fun (and actually because I couldn't find any active pecl extension to use libpcap, so it might as well be something useful). I've named it "SimplePcap".

He includes both the sample code showing the extension's usage and an example of the output from his local "eth0" device. His PHP script uses SWIG to interface with the pcap_t/Packet class structure via this interface file and typemap.

SWIG is really great. I just did some C++ code and then worried about how to integrate it to PHP. Althought it seems that you really need lots of experience with it to actually do more advanced things in the right way. [...] So I guess that sometimes it's more productive to just make the PHP extension than using SWIG. But if you want your code to be run in many languages, this is definitely an excellent library to try!

Over on the Blue Parabola blog Matthew Turland recently posted a new tutorial on using the PHP_CodeSniffer PEAR package to check out how well your code adheres to the coding standard of your choice.

For the sake of consistency [on a client project], the development team had stuff with the coding standard used by the framework itself. However, evaluating the code manually is tedious and time-consuming. There's a solution to this type of problem: the PHP_CodeSniffer package from PEAR, which builds an infrastructure around tokenizers for PHP, CSS, and JavaScript and utilities to detect coding standard violations within code in any of those languages.

He includes an example token output (the codesniffer package is based on the Tokenizer) from a script and walks you through the initial setup of the package, how to create "sniffs" for the code you want to analyze and how to run them using the popular unit testing tool PHPUnit.

DevShed continues their series focusing on the security of your web application in this fifth part of the series. This time they look at preventing attacks on your app via correct authentication.

You will probably recall from the last article that I mentioned the existence of two methods of authentication and discussed the first one, which is through an HTML form. In this article, the fifth one in an eight-part series, we'll start with the second method of authentication. We'll also discuss how attackers may gain access to your system.

This authentication method uses a simple form to let the user pass in their credentials. Unfortunately, because of its simplicity, this also opens it up to three kinds of attacks - password sniffing, reply attacks and brute force attacks.

On the SaniSoft blog Tarique Sani has posted about (and made available for download) some code sniffs for the CakePHP framework. Some problems arose with some of the naming that the framework uses, but with some "tinkering around"...

[It became] apparent that I had to have my own set of Cake sniffs to manage this but a separate standard just for this seemed an over kill and the simplicity of code made it kind of fun to add more standards which I liked but were in different set of sniffs.

You can grab the whole list of sniffs from their downloads. They implemented them as a pre-commit hook on their SVN server even so that developers could not violate the coding standards when they submit their code.

Daniel O'Connor has posted a quick guide to customizing your installation of the PHP_CodeSniffer PEAR package to match the coding standard you'd like.

PHP_CodeSniffer is a PEAR package which detects potential coding problems and enforces your style guide. The default is the PEAR coding standard, but you can easily change that.

His method requires the creation of a custom "FooCodingStandard.php" (named whatever you'd like, of course) that contains a class/method defining the "sniffs" you'd like to use for your standard. Use "pfm" to make it into a package and install it to your system - you'll be all set.