Cara menggunakan wordpress css coding standards

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.

Project history

• On 22nd April 2009, the original project from Urban Giraffe was packaged and published.
• In May 2011 the project was forked and added to GitHub by Chris Adams.
• In April 2012 XWP started to dedicate resources to develop and lead the creation of the sniffs and rulesets for WordPress-Core, WordPress-VIP (WordPress.com VIP), and

   git clone -b master https://github.com/WordPress/WordPress-Coding-Standards.git wpcs
  

  0.
• In May 2015, an initial documentation ruleset was as

   git clone -b master https://github.com/WordPress/WordPress-Coding-Standards.git wpcs
  

  1.
• In 2015, J.D. Grimes began significant contributions, along with maintenance from Gary Jones.
• In 2016, Juliette Reinders Folmer began contributing heavily, adding more commits in a year than anyone else in the five years since the project was added to GitHub.
• In July 2018, version

   git clone -b master https://github.com/WordPress/WordPress-Coding-Standards.git wpcs
  

  2 of the project was released.

Installation

Requirements

The WordPress Coding Standards require PHP 5.4 or higher and PHP_CodeSniffer version 3.7.1 or higher.

Composer

Standards can be installed with the Composer dependency manager:

composer create-project wp-coding-standards/wpcs --no-dev

Running this command will:

1. Install WordPress standards into

    git clone -b master https://github.com/WordPress/WordPress-Coding-Standards.git wpcs
   

   3 directory.
2. Install PHP_CodeSniffer.
3. Register WordPress standards in PHP_CodeSniffer configuration.
4. Make

    git clone -b master https://github.com/WordPress/WordPress-Coding-Standards.git wpcs
   

   4 command available from

    git clone -b master https://github.com/WordPress/WordPress-Coding-Standards.git wpcs
   

   5.

For the convenience of using

 git clone -b master https://github.com/WordPress/WordPress-Coding-Standards.git wpcs

 git clone -b master https://github.com/WordPress/WordPress-Coding-Standards.git wpcs

 git clone -b master https://github.com/WordPress/WordPress-Coding-Standards.git wpcs

Installing WPCS as a dependency

When installing the WordPress Coding Standards as a dependency in a larger project, the above mentioned step 3 will not be executed automatically.

There are two actively maintained Composer plugins which can handle the registration of standards with PHP_CodeSniffer for you:

• composer-phpcodesniffer-standards-plugin
• phpcodesniffer-composer-installer:"^0.6"

It is strongly suggested to

 git clone -b master https://github.com/WordPress/WordPress-Coding-Standards.git wpcs

Standalone

1. Install PHP_CodeSniffer by following its (via Composer, Phar file, PEAR, or Git checkout).

   Do ensure that PHP_CodeSniffer's version matches our , if, for example, you're using VVV.

2. Clone the WordPress standards repository:

    git clone -b master https://github.com/WordPress/WordPress-Coding-Standards.git wpcs
   

3. Add its path to the PHP_CodeSniffer configuration:

    phpcs --config-set installed_paths /path/to/wpcs
   

   Pro-tip: Alternatively, you can tell PHP_CodeSniffer the path to the WordPress standards by adding the following snippet to your custom ruleset:

   <config name="installed_paths" value="/path/to/wpcs" />

To summarize:

cd ~/projects
git clone https://github.com/squizlabs/PHP_CodeSniffer.git phpcs
git clone -b master https://github.com/WordPress/WordPress-Coding-Standards.git wpcs
cd phpcs
./bin/phpcs --config-set installed_paths ../wpcs

And then add the

 phpcs --config-set installed_paths /path/to/wpcs

 git clone -b master https://github.com/WordPress/WordPress-Coding-Standards.git wpcs

 phpcs --config-set installed_paths /path/to/wpcs

You should then see WordPress-Core et al listed when you run

 phpcs --config-set installed_paths /path/to/wpcs

Rulesets

Standards subsets

The project encompasses a super-set of the sniffs that the WordPress community may need. If you use the

 phpcs --config-set installed_paths /path/to/wpcs

You can use the following as standard names when invoking

 git clone -b master https://github.com/WordPress/WordPress-Coding-Standards.git wpcs

•  phpcs --config-set installed_paths /path/to/wpcs
  

  5 - complete set with all of the sniffs in the project
  • WordPress-Core - main ruleset for WordPress core coding standards

  •  git clone -b master https://github.com/WordPress/WordPress-Coding-Standards.git wpcs
    

    1 - additional ruleset for WordPress inline documentation standards

  •  git clone -b master https://github.com/WordPress/WordPress-Coding-Standards.git wpcs
    

    0 - extended ruleset for recommended best practices, not sufficiently covered in the WordPress core coding standards
    • includes WordPress-Core

Note: The WPCS package used to include a WordPress-VIP ruleset and associated sniffs, prior to WPCS 2.0.0. The WordPress-VIP ruleset was originally intended to aid with the WordPress.com VIP coding requirements, but has been superseded. It is recommended to use the official VIP coding standards ruleset instead for checking code against the VIP platform requirements.

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

<config name="installed_paths" value="/path/to/wpcs" />

<config name="installed_paths" value="/path/to/wpcs" />

<config name="installed_paths" value="/path/to/wpcs" />

<config name="installed_paths" value="/path/to/wpcs" />

<config name="installed_paths" value="/path/to/wpcs" />

<config name="installed_paths" value="/path/to/wpcs" />

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

<config name="installed_paths" value="/path/to/wpcs" />

You can find a complete list of all the properties you can change in the wiki.

Recommended additional rulesets

The PHPCompatibility ruleset and its subset PHPCompatibilityWP come highly recommended. The PHPCompatibility sniffs are designed to analyse your code for cross-PHP version 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:

<config name="testVersion" value="5.6-"/>
<rule ref="PHPCompatibilityWP">
    <include-pattern>*\.php$</include-pattern>
</rule>

Whichever way you run it, do make sure you set the

cd ~/projects
git clone https://github.com/squizlabs/PHP_CodeSniffer.git phpcs
git clone -b master https://github.com/WordPress/WordPress-Coding-Standards.git wpcs
cd phpcs
./bin/phpcs --config-set installed_paths ../wpcs

cd ~/projects
git clone https://github.com/squizlabs/PHP_CodeSniffer.git phpcs
git clone -b master https://github.com/WordPress/WordPress-Coding-Standards.git wpcs
cd phpcs
./bin/phpcs --config-set installed_paths ../wpcs

cd ~/projects
git clone https://github.com/squizlabs/PHP_CodeSniffer.git phpcs
git clone -b master https://github.com/WordPress/WordPress-Coding-Standards.git wpcs
cd phpcs
./bin/phpcs --config-set installed_paths ../wpcs

For more information about setting the

cd ~/projects
git clone https://github.com/squizlabs/PHP_CodeSniffer.git phpcs
git clone -b master https://github.com/WordPress/WordPress-Coding-Standards.git wpcs
cd phpcs
./bin/phpcs --config-set installed_paths ../wpcs

How to use

Command line

Run the

 git clone -b master https://github.com/WordPress/WordPress-Coding-Standards.git wpcs

phpcs --standard=WordPress wp-load.php

Will result in following output:

------------------------------------------------------------------------------------------
FOUND 8 ERRORS AND 10 WARNINGS AFFECTING 11 LINES
------------------------------------------------------------------------------------------
 24 | WARNING | [ ] error_reporting() can lead to full path disclosure.
 24 | WARNING | [ ] error_reporting() found. Changing configuration at runtime is rarely
    |         |     necessary.
 37 | WARNING | [x] "require_once" is a statement not a function; no parentheses are
    |         |     required
 39 | WARNING | [ ] Silencing errors is discouraged
 39 | WARNING | [ ] Silencing errors is discouraged
 42 | WARNING | [x] "require_once" is a statement not a function; no parentheses are
    |         |     required
 46 | ERROR   | [ ] Inline comments must end in full-stops, exclamation marks, or
    |         |     question marks
 46 | ERROR   | [x] There must be no blank line following an inline comment
 49 | WARNING | [x] "require_once" is a statement not a function; no parentheses are
    |         |     required
 54 | WARNING | [x] "require_once" is a statement not a function; no parentheses are
    |         |     required
 63 | WARNING | [ ] Detected access of super global var $_SERVER, probably needs manual
    |         |     inspection.
 63 | ERROR   | [ ] Detected usage of a non-validated input variable: $_SERVER
 63 | ERROR   | [ ] Missing wp_unslash() before sanitization.
 63 | ERROR   | [ ] Detected usage of a non-sanitized input variable: $_SERVER
 69 | WARNING | [x] "require_once" is a statement not a function; no parentheses are
    |         |     required
 74 | ERROR   | [ ] Inline comments must end in full-stops, exclamation marks, or
    |         |     question marks
 92 | ERROR   | [ ] All output should be run through an escaping function (see the
    |         |     Security sections in the WordPress Developer Handbooks), found
    |         |     '$die'.
 92 | ERROR   | [ ] All output should be run through an escaping function (see the
    |         |     Security sections in the WordPress Developer Handbooks), found '__'.
------------------------------------------------------------------------------------------
PHPCBF CAN FIX THE 6 MARKED SNIFF VIOLATIONS AUTOMATICALLY
------------------------------------------------------------------------------------------

Using PHPCS and WPCS from within your IDE

• PhpStorm : Please see "" in the PhpStorm documentation.
• Sublime Text : Please see "Setting up WPCS to work in Sublime Text" in the wiki.
• Atom: Please see "Setting up WPCS to work in Atom" in the wiki.
• Visual Studio: Please see "Setting up PHP CodeSniffer in Visual Studio Code", a tutorial by Tom McFarlin.
• Eclipse with XAMPP: Please see "Setting up WPCS when using Eclipse with XAMPP" in the wiki.

Running your code through WPCS automatically using CI tools

• Running in GitHub Actions
• Running in Travis

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 WPCS

Since version 1.2.0, WPCS has a special sniff category

cd ~/projects
git clone https://github.com/squizlabs/PHP_CodeSniffer.git phpcs
git clone -b master https://github.com/WordPress/WordPress-Coding-Standards.git wpcs
cd phpcs
./bin/phpcs --config-set installed_paths ../wpcs

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.