This guide will help you get started with best practices for WordPress development using VS Code.
Once composer is downloaded you'll want to move it to your usr/local/bin directory with the following command:
mv composer.phar /usr/local/bin/composerOnce you have Composer installed and moved to the correct location, open a new terminal session and run the following commands to install needed packages globally on your machine.
- PHP_CodeSniffer with
composer global require "squizlabs/php_codesniffer=*" - Wordpress Coding Standards with
composer global require "wp-coding-standards/wpcs" - A helper to link your new coding standars for you automatically with
composer global require dealerdirect/phpcodesniffer-composer-installer
You then need to add the Composer bin directory to your terminal's PATH. If you're using the default bash shell on macOS, this can be done by adding the following item to your ~/.bash_profile profile (If you are not using the default bash shell on macOS, we'll trust you're experienced enough to add the correct path inclusion to your shell's configuration file):
~/.composer/vendor/bin
Your PATH variable will then look something like this:
/usr/local/bin:/usr/bin:~/.composer/vendor/bin
If you need a guide on how the PATH variable works, you can read about it here
To ensure that everything is installed correctly, open a new terminal shell and run the command phpcs -i. You should get output similar to the following which includes Wordpress-Extra, the standard we'll be implementing.
The installed coding standards are PEAR, Zend, PSR2, MySource, Squiz, PSR1, PSR12, WordPress-VIP, WordPress, WordPress-Extra, WordPress-Docs and WordPress-Core
The following extensions should be searched and installed via the VS Code Extensions panel (Command + Shift + X).
EditorConfig for VS CodephpcsESLint
Once these extensions are installed, you will need to either reload your VS Code workspace or quit and relaunch the application.
There are some directories that we do not want to lint with phpcs because they do not represent our own code and we cannot guarantee their level of quality. In your VS Code User Settings (Command + ,), add the following block of exceptions:
"phpcs.ignorePatterns": [
"*/vendor/*",
"*/wp-admin/*",
"*/wp-includes/*",
"*/node_modules/*"
],
This will prevent phpcs from barking at you for things you can't control. Win! You can also prevent JS linting with a .eslintignore file using .gitignore syntax.
At the root of your project directory you'll want to include a phpcs.xml file. This file tells phpcs which set of rules to use to validate your project's code. There is an example WordPress phpcs.xml file included in this directory.
Note that when you open a project in VS Code, you must open it from the root where your phpcs.xml exists in order for linting to use your project settings correctly
If your phpcs.xml is in the root of your git repo, but you open the wp-content/themes directory directly in your editor, then VS Code will not find your phpcs.xml file and your linting will uses default settings and not the WordPress specific settings.
The .editorconfig file also goes in the root of your project directory. This tells your editor what preferences to default to on a project for tabs vs spaces, level of indention, whether new lines should be required at the end of files, etc.
There is an example editorconfig file included in this repo.
The .eslintrc.js instructs eslint what coding standards to use when linting javascript files. WordPress has it’s own JS coding standards and the example .eslintrc.js file in this directory is configured to follow those standards. They're kind ugly, but at least it's a standard!
Unlike phpcs, you'll want to install eslint directly in each project along with the standards used on that project.
npm install eslint eslint-config-wordpress babel-eslint --save-devWhen not using WordPress, our coding style preference is standard.
Once you have installed the prerequisites, added the phpcs.xml and editorconfig files to your project root, and opened your project in VS Code (ensuring that you're opening it from the root and not a subdirectory in your project) then you should now have linting in place as prescribed by the WordPress coding standards. An easy way to check this is working is to ensure that your editor now barks at you for using spaces for your .php files instead of tabs. Yes, spaces are usually correct for indentation, but that's the WordPress coding standards for you. ¯\_(ツ)_/¯
