Download the PHP package wp-coding-standards/wpcs without Composer
On this page you can find all versions of the php package wp-coding-standards/wpcs. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download wp-coding-standards/wpcs
More information about wp-coding-standards/wpcs
Files in wp-coding-standards/wpcs
Package wpcs
Short Description PHP_CodeSniffer rules (sniffs) to enforce WordPress coding conventions
License MIT
Informations about the package wpcs
WordPress Coding Standards for PHP_CodeSniffer
- Introduction
- Minimum Requirements
- Installation
- Composer Project-based Installation
- Composer Global Installation
- Updating your WordPressCS install to a newer version
- Using your WordPressCS install
- Rulesets
- Standards subsets
- Using a custom ruleset
- Customizing sniff behaviour
- Recommended additional rulesets
- How to use
- Command line
- Using PHPCS and WordPressCS from within your IDE
- Running your code through WordPressCS automatically using Continuous Integration tools
- Fixing errors or ignoring them
- Tools shipped with WordPressCS
- Contributing
- Funding
- License
Introduction
This project is a collection of PHP_CodeSniffer rules (sniffs) to validate code developed for WordPress. It ensures code quality and adherence to coding conventions, especially the official WordPress Coding Standards.
This project needs funding. Find out how you can help.
Minimum Requirements
The WordPress Coding Standards package requires:
For the best results, it is recommended to also ensure the following additional PHP extensions are enabled:
Installation
As of WordPressCS 3.0.0, installation via Composer using the below instructions is the only supported type of installation.
Composer will automatically install the project dependencies and register the rulesets from WordPressCS and other external standards with PHP_CodeSniffer using the Composer PHPCS plugin.
If you are upgrading from an older WordPressCS version to version 3.0.0, please read the Upgrade guide for ruleset maintainers and end-users first!
Composer Project-based Installation
Run the following from the root of your project:
Composer Global Installation
Alternatively, you may want to install this standard globally:
Updating your WordPressCS install to a newer version
If you installed WordPressCS using either of the above commands, you can upgrade to a newer version as follows:
Using your WordPressCS install
Once you have installed WordPressCS using either of the above commands, use it as follows:
Pro-tip: For the convenience of using
phpcs
as a global command, use the Global install method and add the path to the%USER_DIRECTORY%/Composer/vendor/bin
directory to thePATH
environment variable for your operating system.
Rulesets
Standards subsets
The project encompasses a super-set of the sniffs that the WordPress community may need. If you use the WordPress
standard you will get all the checks.
You can use the following as standard names when invoking phpcs
to select sniffs, fitting your needs:
WordPress
- complete set with all of the sniffs in the projectWordPress-Core
- main ruleset for WordPress core coding standardsWordPress-Docs
- additional ruleset for WordPress inline documentation standardsWordPress-Extra
- extended ruleset with recommended best practices, not sufficiently covered in the WordPress core coding standards- includes
WordPress-Core
Using a custom ruleset
If you need to further customize the selection of sniffs for your project - you can create a custom ruleset file.
When you name this file either .phpcs.xml
, phpcs.xml
, .phpcs.xml.dist
or phpcs.xml.dist
, PHP_CodeSniffer will automatically locate it as long as it is placed in the directory from which you run the CodeSniffer or in a directory above it. If you follow these naming conventions you don't have to supply a --standard
CLI argument.
For more info, read about using a default configuration file. See also the provided WordPressCS fully annotated example ruleset in the PHP_CodeSniffer documentation.
Customizing sniff behaviour
The WordPress Coding Standard contains a number of sniffs which are configurable. This means that you can turn parts of the sniff on or off, or change the behaviour by setting a property for the sniff in your custom [.]phpcs.xml[.dist]
file.
You can find a complete list of all the properties you can change for the WordPressCS sniffs in the wiki.
WordPressCS also uses sniffs from PHPCSExtra and from PHP_CodeSniffer itself. The README for PHPCSExtra contains information on the properties which can be set for the sniff from PHPCSExtra. Information on custom properties which can be set for sniffs from PHP_CodeSniffer can be found in the PHP_CodeSniffer wiki.
Recommended additional rulesets
PHPCompatibility
The PHPCompatibility ruleset and its subset PHPCompatibilityWP come highly recommended. The PHPCompatibility sniffs are designed to analyse your code for cross-version PHP compatibility.
The PHPCompatibilityWP ruleset is based on PHPCompatibility, but specifically crafted to prevent false positives for projects which expect to run within the context of WordPress, i.e. core, plugins and themes.
Install either as a separate ruleset and run it separately against your code or add it to your custom ruleset, like so:
Whichever way you run it, do make sure you set the testVersion
to run the sniffs against. The testVersion
determines for which PHP versions you will receive compatibility information. The recommended setting for this at this moment is 7.0-
to support the same PHP versions as WordPress Core supports.
For more information about setting the testVersion
, see:
- PHPCompatibility: Sniffing your code for compatibility with specific PHP version(s)
- PHPCompatibility: Using a custom ruleset
VariableAnalysis
For some additional checks around (undefined/unused) variables, the VariableAnalysis
standard is a handy addition.
VIP Coding Standards
For those projects which deploy to the WordPress VIP platform, it is recommended to also use the official WordPress VIP coding standards ruleset.
How to use
Command line
Run the phpcs
command line tool on a given file or directory, for example:
Will result in following output:
Using PHPCS and WordPressCS from within your IDE
The wiki contains links to various in- and external tutorials about setting up WordPressCS to work in your IDE.
Running your code through WordPressCS automatically using Continuous Integration tools
Fixing errors or ignoring them
You can find information on how to deal with some of the more frequent issues in the wiki.
Tools shipped with WordPressCS
Since version 1.2.0, WordPressCS has a special sniff category Utils
.
This sniff category contains some tools which, generally speaking, will only be needed to be run once over a codebase and for which the fixers can be considered risky, i.e. very careful review by a developer is needed before accepting the fixes made by these sniffs.
The sniffs in this category are disabled by default and can only be activated by adding some properties for each sniff via a custom ruleset.
At this moment, WordPressCS offer the following tools:
WordPress.Utils.I18nTextDomainFixer
- This sniff can replace the text domain used in a code-base. The sniff will fix the text domains in both I18n function calls as well as in a plugin/theme header. Passing the following properties will activate the sniff:old_text_domain
: an array with one or more (old) text domain names which need to be replaced;new_text_domain
: the correct (new) text domain as a string.
Contributing
See unit testing the standard.
Funding
If you want to sponsor the work on WordPressCS, you can do so by donating to the PHP_CodeSniffer Open Collective.
License
See LICENSE (MIT).
All versions of wpcs with dependencies
ext-filter Version *
ext-libxml Version *
ext-tokenizer Version *
ext-xmlreader Version *
squizlabs/php_codesniffer Version ^3.9.0
phpcsstandards/phpcsutils Version ^1.0.10
phpcsstandards/phpcsextra Version ^1.2.1