Setting up PHP CodeSniffer on Sublime for applying WordPress Coding Standards

I spent a shameful amount of time trying to troubleshoot various issues while trying to make it work. The following are the steps I used to finally get it right.

The software that we’ll rely on

  • Sublime Text 3 – as it’s the most common and rather light code editor out there;
  • PHP 5.4 or higher;
  • PHP CodeSniffer 3.3.1 or higher. If you got a lower version, you’d be getting some weird errors when running it against the WordPress standards, as it’s WPCS that requires that version;
  • PHP Mess Detector;
  • PHP Code Sniffer Sublime package;
  • PHP Code Beautifier Sublime package;
  • Composer;
  • Debian based Linux. You can do that whole setup on almost any other OS, but there will be some differences in the commands. I did it on a Linux Mint 19.2 Tina, based on Ubuntu 18.04 bionic.

Step 1: Installation

Let’s assume that you already have Sublime Text installed. Check your version just to make sure you are working on v3 or higher.

subl -v

Checking PHP’s version is done in a similar manner:

php -v

There are several ways of installing PHP CodeSniffer, Mess Detector and Composer.

1.1. You could start with the easiest one, trying to get these packages from the distribution’s package manager:

sudo apt install composer php-codesniffer phpmd

After the installation is over, check whether phpcs that you just installed is 3.3.1 or higher version. If it’s lower, better remove it and a more manual approach.

1.2. Manually installing the needed packages isn’t too much of a deal, but updating them would cost you some extra efforts, compared to having them through your package manager. Here are the commands for each of the packages you need. If you have some of them from your package manager, don’t waste your time getting them through this method.

mkdir ~/bin && cd ~/bin //preparing a directory where we’ll download all the software we need

git clone phpcs

git clone git://

curl -s | php

After we’ve downloaded them, we need to make them executable without having to write relative or absolute paths:

sudo ln -s ~/bin/phpcs/bin/phpcs /usr/local/bin/phpcs
sudo ln -s ~/bin/phpmd/src/bin/phpmd /usr/local/bin/phpmd
sudo ln -s ~/bin/phpcs/bin/phpcbf /usr/local/bin/phpcbf
sudo ln -s ~/bin/composer.phar /usr/local/bin/composer

There’s one more step required for PHP Mess Detector:

cd ~/bin/phpmd && composer install

If installation is done properly, you should have the given commands available: phpcs, phpmd, phpcbf and composer.

Step 2. Getting WordPress Coding Standards

You could clone the repo straight from GitHub:

git clone ~/bin/wpcs

That’s it. Now you need to

Step 3. Configure PHP CodeSniffer to work with WPCS

Two commands are needed here. First will let phpcs know that there’s a bunch of new standards in town. To see the current ones, run:

phpcs -i

If you don’t see WordPress there, which is actually what usually happens with a clean install, run this:

phpcs --config-set installed_paths ~/bin/wpcs

At this point, if you check with the previous command again, you should see something like this:

The installed coding standards are MySource, PSR12, PSR2, PSR1, PEAR, Zend, Squiz, WordPress-Docs, WordPress-Extra, WordPress-Core and WordPress

Cool. Now let’s make WordPress the default standard:

phpcs --config-set default_standard WordPress

Step 4. Check if it works in command line

Create a test file with some badly formatted PHP. Here’s a sample for you:

<?php $JustAVar ='nope'; if($JustAVar == true) { echo 'Hi there!'; ///whatever

Let’s have this code in a new file, located in /tmp/ugly.php

The test would be to run phpcs /tmp/ugly.php. The result we are looking for, is something like this:

FILE: /tmp/ugly.php
1 | ERROR | [ ] Missing file doc comment
1 | ERROR | [ ] Variable “$JustAVar” is not in valid snake_case format, try “$just_a_var”
1 | ERROR | [x] Expected 1 space after “=”; 0 found
1 | ERROR | [x] Space after opening control structure is required
1 | ERROR | [x] Expected 1 space(s) after IF keyword; 0 found
1 | ERROR | [x] Inline control structures are not allowed
1 | ERROR | [ ] Variable “$JustAVar” is not in valid snake_case format, try “$just_a_var”
1 | WARNING | [ ] Found: ==. Use strict comparisons (=== or !==).
1 | ERROR | [ ] Use Yoda Condition checks, you must.
1 | ERROR | [x] Each PHP statement must be on a line by itself
2 | ERROR | [x] No space found before comment text; expected “// /whatever” but found “///whatever”
3 | ERROR | [ ] PHP syntax error: syntax error, unexpected end of file
Time: 130ms; Memory: 8MB

Neat, isn’t it?

It’s time to

Step 5. Configure Sublime Text

If you still don’t have the two Sublime packages that I mentioned earlier, install them:

Press Ctrl + Shift + P, type “install” and select “phpcs”, then repeat the same procedure for “CodeBeautifier”.

Now you need to edit the PHP Code Sniffer package configuration in order to set the executable paths for phpcs, phpcbf and phpmd. What I did was copy the default configuration from Preferences -> Package Settings -> PHP Code Sniffer -> Settings - Default in Settings - User and edit the following variables:

"phpcs_executable_path": "/usr/local/bin/phpcs"
"phpcbf_executable_path": "/usr/local/bin/phpcbf"
"phpmd_executable_path": "/usr/local/bin/phpmd"

Furthermore, you should comment out settings for PHP-CS-Fixer, or even delete them, as you won’t be using this package (unless you actually plan on using it).

Finally, you should set the standard to be used for all of the commands to WordPress. Look for lines, with a key "--standard" and set them all to WordPress like this:

"--standard": "WordPress"

Feel free to check the rest of the settings, available in the configuration in order to avoid unwanted automatic fixes or checks.

After you save the configuration, open that funny file again:

subl /tmp/ugly.php

Save it and see if you get any notifications about it. Fixing some of these would be as simple as right-clicking in the editor and selecting PHP Code Sniffer -> Fix this file -> PHP Code Beautifier (phpcbf).

Have in mind that there might be some issues with the configuration, leading to triggering code fixing even if you didn’t set it this way, so make sure to test all of this before running it on a client’s codebase.

This article was originally created for my team-mates from DevriX.

Leave a Reply

Your email address will not be published. Required fields are marked *