#Php 5.2 to 5.4 issues code

On a Unix / Linux style system, this will do the trick: What we can do easily enough, however, is run PHP from the command line to lint all of our files, ensuring at least that we havenвЂ™t left off a semicolon or something.

#Php 5.2 to 5.4 issues code

In fact, we can have a basic PHP error in our code that breaks PHP, and our code sniffs wonвЂ™t tell us. But thatвЂ™s not exactly the same as checking for code that runs without error. Great, now we can use static analysis to check for rule violations.

So hereвЂ™s a separate file that we can call phpcs-5.2.xml just for those PHP 5.2+ compatibility checks. First, we can create a second configuration file just for scanning for PHP 5.2 incompatibility and second, we need to run another rule - PHP 5.4 made it possible to use short echo tags whether or not the server allowed short open tags, but that wonвЂ™t work in PHP 5.3 or earlier. With that config file in place, calling phpcs from the command line will analyse the main plugin file, and any code inside two folders (includes and views).Д«ut what about the code that needs to be compatible with PHP 5.2? Two tricks help us achieve that. Some basic coding standards sniffs for this project. HereвЂ™s a simple example that runs the tests for minimum PHP 5.4 support it will produce warnings for any code found that wonвЂ™t run in PHP versions from 5.4 to current versions (7.2 at the moment). The easiest way to run the code sniffer is to create a custom configuration file called phpcs.xml, and detail what we want PHPCS to do. There are simple instructions there for setting up the code sniffer to run across our code. But the best news is that there is a custom rule set for checking PHP cross-version compatibility. PHP_CodeSniffer can scan PHP code for coding standard violations - a really handy tool for keeping things neat, and even catching some bugs before we get stuck into testing. Or we can cheat, and check our code with static analysis to see if thereвЂ™s anything there that shouldnвЂ™t be there! Smashing Magazine covered this well with its article, An Introduction To Automated Testing Of WordPress Plugins With PHPUnit. This is what continuous integration is really good at doing.

The best way is, of course, to test all of the code in all of the versions. OK, so now the tricky bit: making sure that the code will actually run on all of those supported versions. What that minimum version is depends on the plugin writer, and maybe even on the plugin - for example, some of my plugins require version 7+, some require version 5.6+, some version 5.4+, and some still run fine on 5.2.4.

What many plugin writers are doing (myself included) is testing for a minimum PHP version that weвЂ™re happy to support, and exiting early with a notification to the site admin if we canвЂ™t run in their environment. Wow! 2018 is almost over, PHP 5.6 is coming off life support soon, but WordPress still runs on PHP 5.2.4 - which means at least some parts of any plugin written for WordPress today still need to run successfully on PHP 5.2.4 as well. If you are in a legacy environment where you only have older PHP or MySQL versions, WordPress also works with PHP 5.2.4+ On its Requirements page, WordPress recommends a minimum of PHP version 7.2 at time of writing, but it also says: Worst, because when we write plugins for WordPress, we get that backwards compatibility shackled to us as well. Best, because it can run on many different environments, even at the latest versions. One of the best, and worst, things about WordPress is its dedication to backwards compatibility. PHPCS and the PHPCompatibility rules can help us ensure that. Even if we test for a minimum version and bail early on an old PHP version, our tests need to run on the lowest common denominator. When writing plugins for WordPress, itвЂ™s important to keep the code compatible with supported versions of PHP.