WordPress Coding Standards as part of your CI strategy

Ship your code with confidence.

It is always a good thing to follow a certain coding style when writing code. WordPress is unfortunately ripe for spaghetti coding, aka doing whatever you want. It doesn’t follow any strict object oriented approach and doesn’t use an MVC pattern. But you can still write good code if you stick to certain rules and conventions.

Why you need to apply WordPress coding standards to your codebase

  • Avoid your codebase becoming a big mess. If there are no standards applied to your code, then it can quickly become a big mess. Especially when there is more developers working on the same code. If they’re not kept in check, things escalate fast.

  • Best practices. It is beneficial to the community when everyone is adopting the same practices when writing code.

  • Security. Code standards should include checks to make sure that the code is securely written. It’s easy to forget a nonce on a form or to output a variable that is not escaped. WordPress coding standards define how to write secure code and should be strictly enforced.

  • Documented code is much easier to read and understand. Your code standards should enforce documentation of classes, methods, variables etc. Having documented code is again a win for everyone as the code becomes much clearer when trying to add to it or refactor it.

There are coding standards for PHP, Html, JavaScript and Accessibility. Read all about it in the code handbook.

PHPCS and WPCS

The WordPress Coding Standards project is a whole set of PHPCS (PHP_CodeSniffer) rules to make sure your code written for WordPress follows the outlined conventions.

Install and setup

Install and setup

Make sure your setup is correct by running phpcs -i:

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

If everything went well, the WordPress coding standards should be listed (WordPress, WordPress-Extra, WordPress-Docs and WordPress-Core)

Custom Ruleset

The behaviour of some sniffs can be changed by setting certain sniff properties in your ruleset. PHP_CodeSniffer allows developers to design their own coding standards by creating a simple ruleset XML file that both pulls in sniffs from existing standards and customises them for the developer’s needs. Annotated ruleset

Running

phpcs --report=full --standard=WordPress --ignore=*/vendor/* ./ --extensions=php

if using the WordPress coding standards, or if using your custom ruleset:

phpcs --report=full --standard=./codesniffer-ruleset.xml --ignore=*/vendor/* ./ --extensions=php

Example output:

FILE: ...rojects/myproject/myfile.php
----------------------------------------------------------------------
FOUND 4 ERRORS AFFECTING 4 LINES
----------------------------------------------------------------------
34 | ERROR   | [x] Expected 1 spaces before closing bracket; 0 found
36 | ERROR | All output should be run through an escaping function
    |       | (see the Security sections in the WordPress Developer
    |       | Handbooks), found '$image_src'.
90 | ERROR   | [x] String "Create a Configuration File" does not require
    |         |     double quotes; use single quotes instead
63 | ERROR   | [ ] Missing wp_unslash() before sanitization.
----------------------------------------------------------------------

From within your editor

I use VS Code and have the phpcs extension installed. Errors and warning show up in the problems tab. Simple as that. There is packages for most editors and IDs

Example output:

VS Code

As part of your CI strategy

When using Continuous Integration we can automatically check if the code you are writing follows the coding standards for every commit that get pushed to the repo.

Codeship is our main workhorse when it comes to Contious Integration and Deployment, in some projects we also use Bitbucket Pipelines and Travis.

Codeship setup

Switch to the tests tab https://app.codeship.com/projects/XXXXX/tests/edit.

Tests

Setup Commands


# Use PHP 7.2
phpenv local 7.2

## Install PHP CodeSniffer
git clone https://github.com/squizlabs/PHP_CodeSniffer.git php-codesniffer

# Install WPCS
git clone -b master https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards.git wordpress-coding-standards

# Set install path for WordPress Coding Standards.
./php-codesniffer/bin/phpcs --config-set installed_paths ../wordpress-coding-standards

# Show installed standards (helpful for Debugging)
./php-codesniffer/bin/phpcs -i

# Refresh our path.
phpenv rehash

Test commands

./php-codesniffer/bin/phpcs --report=full --standard=~/clone/yourpath/codesniffer-ruleset.xml --ignore=*/vendor/*,*/wordpress-coding-standards/*,*/php-codesniffer/*,*/node_modules/* ~/clone/yourpath --extensions=php
  • The ~/clone directory is where your code is located after Codeship has cloned it.

If you code doesn’t meet the standards, well…Codeship tests will fail 😞

Fail

Conclusion

Consistency is key. Our Editors of course help us a lot, we have linters, formatters and other tools that help us keeping the code style consistent. I recommend taking this a step further and get this in your CI workflow to make sure of that and let you focus on writing your best code.

Success

Happy Coding!