As I mentioned yesterday, if you want to use PHPCodeSniffer+PHPCompatibilitymake sure you are using the 2.9 version of PHPCodeSniffer. Failing to see the notice in the PHPCompatibility Requirements section about it being incompatible with PHPCS3.0 will lead to several hours of hair-pulling and cursing at your screen.
The PHPCompatibility standard is currently not compatible with PHPCS 3.0If you are unfamiliar with PHPCodeSniffer (PHPCS), it parses your codebase looking for violations a standard(s) (or Sniffers) you've selected. Additional standards can be added to PHPCS and used to validate code. PHPCompatibility is an example of a PHPCS standard extension. It allows us to check our codebase for compatibility with higher and lower versions of PHP. PHPCS is available as a phar package which makes it easy to install into our web account for checking our code.
Just like yesterday, PHPCS can be installed locally if you would prefer to evaluate your code there instead of on the testing or development environment. macOS and *nix should be able to follow the directions here; windows users will need to either have PHP installed, or look at running a VM with PHP (there are lots of docker options available).
First we need PHPCS. After logging into your account vis SSH, and navigating to your web account space, issue the following:
[bash]curl -OL https://github.com/squizlabs/PHP_CodeSniffer/releases/download/2.9.0/phpcs.phar[/bash]
Curl should produce a status indicator and notify you when it is finished. You can test the phar file to make sure it downloaded correctly by running
[bash]php phpcs.phar --version[/bash]
which should output
[bash]PHP_CodeSniffer version 2.9.0 (stable) by Squiz (http://www.squiz.net) [/bash]
Now we need to install PHPCompatibility. Unfortunately, it is not available as a phar package so we'll need to clone the the repository. Before we do that we'll need to create a new directory where we'll store all our Standards plugins. (Technically you don't need to do this, but it comes in handy if you decide later you want to continue to use PHPCS and want to add in more standards beyond PHPCompatibility). For this example, I created a directory extrastandards and navigated into it. Clone the PHPCompatibility repository:
[bash]git clone https://github.com/wimg/PHPCompatibility.git[/bash]
Which will create the directory PHPCompatibility and place the contents of the repository into it. Next navigate back to where you stored phpcs.phar. Before we can scan our codebase, we need to tell PHPCS where we are storing the additional standards we want to use. To let it know our additional standards are in our extrastandards directory, issue the following:
[bash]php phpcs.phar --config-set installed_paths extrastandards [/bash]
PHPCS should report
[bash]Config value "installed_paths" added successfully[/bash]
In addition, you should notice a CodeSniffer.conf file has been created. (If you ever need to change the standards location, or add to it, you'll need to edit this .conf file). You can now verify the available standards by doing:
[bash] php phpcs.phar -i [/bash]
PHPCS should report that the installed standards includes our PHPCompatibility standard.
[bash] The installed coding standards are MySource, PEAR, PHPCS, PSR1, PSR2, Squiz, Zend and PHPCompatibility [/bash]
We're now ready to start checking our code. To do so, type in the following:
[bash] php -d date.timezone=America/Chicago phpcs.phar --standard=PHPCompatibility --runtime-set testVersion 7.0 www/wp-contents/plugins/mizzoumvc [/bash]
The -d date.timezone=America/Chicago
is there because, for some reason, the timezone is not set in the default php.ini file (which is what PHP will use when running from the command line) on our web servers. This simply sets the timezone so the warning about not having the timezone set isn't included in the list of errors. --standard=PHPCompatibility
is how we tell PHPCS which standard we want to evaluate against. --runtime-set testVersion 7.0
is how we tell PHPCompability which version of PHP we want to test against.
If you get nothing back after running the command, congratulations! Your code should be compatible with 7.0 (though as I said yesterday, I'd test against a couple of these tools just to make sure nothing is missed). Using the same example code from yesterday, PHPCompatibility reported the following:
FILE: ...foo.missouri.edu/www/wp-content/plugins/mizzoumvc/css/style.css
--------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
--------------------------------------------------------------------
1 | WARNING | File appears to be minified and cannot be processed
--------------------------------------------------------------------
Time: 14.16 secs; Memory: 36.25Mb
Given this report and that the issues identified by php7cc and php7mar yesterday were all false-positives, I'm fairly confident this particular codebase is ready for the migration, and I can move on to the next codebase.
Hopefully, one if not all three of these tools will help you in prepping for this migration. As always, if you have any questions or run into any issues and need help, do not hesitate to reach out to me. As I have mentioned previously, we want this migration to go as smoothly and transparently as humanly possible and will do whatever we can to make that happen.