Issue 1:
This Section is missing-
Attributes and Tags > For machines:

https://developer.wordpress.org/coding-standards/wordpress-coding-standards/html/#attributes-and-tags
Screenshot- http://prntscr.com/ql59o1

Issue 2:
This Section is missing-
Quotes #Quotes > Correct:

https://developer.wordpress.org/coding-standards/wordpress-coding-standards/html/#quotes
Screenshot- http://prntscr.com/ql5934

It appears that there's no link to, or information about, the PHPCS rules from anywhere on the Coding Standards Handbook.

A follow up to #44/#45

https://developer.wordpress.org/coding-standards/wordpress-coding-standards/html/#quotes

Source: https://github.com/WordPress/wpcs-docs/blob/master/wordpress-coding-standards/html.md#L46-L49

<input type="text" name="email" disabled="disabled" />
<input type='text' name='email' disabled='disabled' />

This can be observered on the following pages (possibly others also)

• https://developer.wordpress.org/coding-standards/inline-documentation-standards/php
• https://developer.wordpress.org/coding-standards/inline-documentation-standards/javascript
• https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php
• https://developer.wordpress.org/coding-standards/wordpress-coding-standards/html

cc @coffee2code

The below example of Correct and Incorrect is not available in No Shorthand PHP Tags section of PHP Coding Standards.

Correct:

<?php ... ?>
<?php echo $var; ?>

Incorrect:

<? ... ?>
<?= $var ?>

Include the inclusion of declare(strict_types=1); in the standards.

It uses modern PHP features prevents errors early on and is a good standard.

Links in JavaScript Coding Standards page are pointing to make core handbook pages instead of new coding standard pages on DevHub.

We have a section in the PHP coding standards called Indentation:

However, the first "exception" to it (second sentence) is about mid-line alignment. Would there be value in extracting this into a separate Alignment section? The presence of the "Rule of thumb" at the bottom of the section seems like a smell that these items could be documented separately.

Page:-
https://wordpress.org/about/license/

Screenshot-
http://prntscr.com/qlrdmn

ISSUE 1:
Replace this link-
https://drupal.org/licensing/faq/
With
https://www.drupal.org/about/licensing

ISSUE 2:
Replace this link-
https://www.s9y.org/
With
https://docs.s9y.org/

ISSUE 3:
This link is not working at all.
http://habariproject.org/en/

Currently, the main branch of this repo is named master and all the other projects are using trunk or main as the main branches instead of master. We should do the same.

The docs are using some form of automatic deployment to the handbook, and I reckon that that automatic way pulls the changes from the master branch, so that part should be updated accordingly (otherwise the update process would be broken).

I tried checking the handbook meta plugin, but I didn't find anything useful so anybody with information on how this is done can comment here. I don't mind creating a meta patch for this.

To ensure the correct title of each post is created on initial import the "title" or each manifiest item should be specified, via https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/plugins/wporg-markdown/README.md#L20:

"title - Title to use when creating post. Used temporarily, will be updated from the Markdown file. If not specified, defaults to slug (but will be updated from Markdown source)."

Links in Inline Documentation Standards page are pointing to make core handbook pages instead of new coding standard pages on DevHub.

Introduction

Given that the PER coding styles were released 8 days ago, and we've made progress in updating the coding standards a bit in the last few months - markdown updates, update some phrasing, removed outdated references, updated examples (still pending in PR #92), I thought that it wouldn't be a bad idea to give some proper structure to the PHP WordPress Coding Standards (PHP WPCS).

By structure, I mean grouping the currently disjointed parts of the CS into some logical groups, like what PER standards (which are just PSR-12 standards at the moment) are doing.

Current status

Currently, we have the following sections

Single and Double Quotes
Indentation
Brace Style
Use `elseif`, not `else if`
Declaring Arrays
Closures (Anonymous Functions)
Multiline Function Calls
Regular Expressions
Opening and Closing PHP Tags
No Shorthand PHP Tags
Remove Trailing Spaces
Space Usage
Formatting SQL statements
Database Queries
Naming Conventions
Only one object structure (class/interface/trait) per file
Self-Explanatory Flag Values for Function Arguments
Interpolation for Naming Dynamic Hooks
Ternary Operator
Yoda Conditions
Clever Code
Error Control Operator `@`
Don't `extract()`

The PER style has the following main sections:

Overview
General
Declare Statements, Namespace, and Import Statements
Classes, Properties, and Methods
Control Structures
Operators
Closures
Anonymous Classes

With subsections it looks like this:

2. General
  2.1 Basic Coding Standard
  2.2 Files
  2.3 Lines
  2.4 Indenting
  2.5 Keywords and Types
3. Declare Statements, Namespace, and Import Statements
4. Classes, Properties, and Methods
  4.1 Extends and Implements
  4.2 Using traits
  4.3 Properties and Constants
  4.4 Methods and Functions
  4.5 Method and Function Arguments
  4.6 abstract, final, and static
  4.7 Method and Function Calls
5. Control Structures
  5.1 if, elseif, else
  5.2 switch, case
  5.3 while, do while
  5.4 for
  5.5 foreach
  5.6 try, catch, finally
6. Operators
  6.1. Unary operators
  6.2. Binary operators
  6.3. Ternary operators
7. Closures
8. Anonymous Classes

which is a lot more structured and clear in my opinion.

Proposal

The proposal is to have the following grouping in the PHP WPCS:

General
  Opening and Closing PHP Tags
  No Shorthand PHP Tags
  Brace Style
  Single and Double Quotes
  Multiline Function Calls

Naming and declarations
  Naming Conventions
  Interpolation for Naming Dynamic Hooks
  Declaring Arrays

Control structures
  Use `elseif`, not `else if`

Whitespace
  Space Usage
  Indentation
  Remove Trailing Spaces

Object-oriented programming
  Only one object structure (class/interface/trait) per file

Operators
  Ternary Operator

Database
  Database Queries
  Formatting SQL statements

Closures (Anonymous Functions)

Best recommendations
  Regular Expressions
  Self-Explanatory Flag Values for Function Arguments
  Clever Code
  Yoda Conditions
  Error Control Operator `@`
  Don't `extract()`

This will give a better structure - knowing where things should be located will help find what you need quickly, as well as prepare for the addition of more modern PHP constructs defined in the make post.

The content inside the existing standards will stay the same, so this is just a grouping change (adding new chapters and putting the other parts inside correct chapters).

Please let me know if you think that some sections belong in other chapters, or if you think that the chapters themselves need a better name.

CC @GaryJones @ntwb @jrfnl

Links in WordPress Coding Standard page are pointing to make core handbook pages instead of new coding standard pages on DevHub.

Links in PHP Coding Standards page are pointing to make core handbook pages instead of new coding standard pages on DevHub.

Titles for PHP Documentation Standards and JavaScript Documentation Standards are switched.

Related to the prematurely closed #38, which was partially worked around in #meta5346 and the non-worked-around part has now been raised in #meta5443 (which I'm going to close since this ticket will address the issue), formatting for code encapsulated within code shortcodes are not always properly retained (in particular, HTML entity display). I'll quote what I said there:

This is an outstanding issue in general that for which the likely culprit is the SyntaxHighlighter Evolved plugin's handling of code shortcodes. Its block handling is superior and doesn't have this issue, but in this case the Code Standards Handbook is fully imported from GitHub, and thus originates as text in a Markdown format.

I believe the issue would be resolved if the source documents avoided the use of code shortcodes (e.g. [php], [html], [css], [javascript], or [code]) and instead used triple backticks (with optional language hinting) without pre-encoding, e.g.

```html
<?php if ( have_posts() ) : ?>
<div class="hfeed">
    <?php while ( have_posts() ) : the_post(); ?>
         <article id="post-" class="">
             <!-- ... -->
         </article>
    <?php endwhile; ?>
</div>
<?php endif; ?>
```

The Block Editor Handbook is also imported from GitHub and uses backticks (e.g. [a source .md file[(https://github.com/WordPress/gutenberg/edit/master/docs/designers-developers/developers/themes/theme-json.md) and its resultant handbook page) which could be used for reference.

What needs to happen:

• Convert all existing uses of shortcodes (for 'css', 'html', 'js', and 'php') to Markdown code fence notation
• Update style guide to require use of markdown instead of shortcodes
• Update style guide to render the Markdown code examples intended to demonstrate use of code fences rather than formatting the code for display
• Update style guide to include 'HTML' as a type of 'Fenced Code Block'

PR forthcoming.

Links in CSS Coding Standards page are pointing to make core handbook pages instead of new coding standard pages on DevHub.

The Formatting SQL Statements section currently includes a paragraph on string and integer placeholders:

%s is used for string placeholders and %d is used for integer placeholders. Note that they are not 'quoted'! $wpdb->prepare() will take care of escaping and quoting for us. The benefit of this is that it is easy to see at a glance whether something has been escaped or not because it happens right when the query happens.

Is it worth adding that (when WordPress 6.1 is available) developers will be able to use %i for Identifiers (e.g. field and table names)?

Maybe this should be a separate paragraph? and maybe only added when 6.1 is released in October?

The intention is to avoid the risky feature where WordPress does not quote string/integer/float placeholders when they contain argnum/format, something that can be used today when (incorrectly) trying to use a variable for field/table names, e.g.

$field = 'bad`quoting';
$value = '5 AND 1=1';

$wpdb->prepare( 'WHERE `%1$s` = %2$s', $field, $value ); // WHERE `bad`quoting` = 5 AND 1=1

This relates to WordPress Ticket #52506, Changeset #53575, and Pull Request #2072 for WordPress-Coding-Standards (thanks to Juliette, who has done a nice writeup about it, and pointed me to this repo).

At https://developer.wordpress.org/coding-standards/inline-documentation-standards/php/#1-1-parameters-that-are-arrays, the link titled 'Hooks' points to a broken url.

I have corrected the link in the below PR:

#126

Worth adding a directory of exports from IDEs, with instructions on how to import them, so that the code formatted by IDEs at least start off as close to WP CS as possible?

See https://github.com/joomla/coding-standards/tree/master/Joomla/IDE

The first link of the coding standards page to "Commit Messages" goes to a 404: https://developer.wordpress.org/coding-standards/commit-messages/

To sync the content of this repo to https://developer.wordpress.org/coding-standards we need to set that up for WordPress.org

A first pass of the code needed is in meta-3377.patch

Ticket: https://meta.trac.wordpress.org/ticket/3377
Patches: https://meta.trac.wordpress.org/attachment/ticket/3377/

If Good, Better comments are green color & Bad, Not Acceptable comments are in red color. Also Not bad & it have better solution but acceptable comments are in yellow color. Then it will increase readability & understandability of docs.

In the Javascript Coding Standards page of the Handbook:
https://developer.wordpress.org/coding-standards/wordpress-coding-standards/javascript/#naming-conventions

There is a link to the WordPress PHP coding standards page with a #naming-conventions anchor:

https://make.wordpress.org/core/handbook/coding-standards/php/#naming-conventions

This page does not have a naming conventions section or anchor. Therefore my PR is to remove the link altogether as it is not useful.

Links in index page are pointing to make core handbook pages instead of new coding standard pages on DevHub.

Idea that Juliette sugessted in the PR was to standardize the order of certain parts of a rule in the handbook:

1. CS rules
2. Possible code samples
3. Usage in Core (if needed)
4. PHP feature info (if needed)

Also, the color of the boxes would be:

• [info] (blue) - for information about PHP features and how to use them.
• [alert] (yellow) - for information on whether or not something can be used in WP Core.
• [warning] (red) - for anything really problematic (like using the wp namespace prefix).