sdc-build-wp 3.7.2 → 4.0.0

package/vendor/wp-coding-standards/wpcs/WordPress-Core/ruleset.xml

@@ -0,0 +1,948 @@
+<?xml version="1.0"?>
+<ruleset xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="WordPress Core" xsi:noNamespaceSchemaLocation="https://raw.githubusercontent.com/PHPCSStandards/PHP_CodeSniffer/master/phpcs.xsd">
+
+	<description>Non-controversial generally-agreed upon WordPress Coding Standards</description>
+
+	<!-- Default tab width for indentation fixes and such. -->
+	<arg name="tab-width" value="4"/>
+
+	<!--
+		 Trigger error if PHPCSUtils cannot be found.
+		 PHPCSUtils does not contain any sniffs, so this rule isn't strictly necessary, but
+		 by having this here anyway, if PHPCSUtils is missing, the user will get a
+		 descriptive error message during the loading of the ruleset instead of
+		 a fatal "class not found" error once the sniffs start running.
+	-->
+	<rule ref="PHPCSUtils"/>
+
+	<!--
+	#############################################################################
+	Handbook: General - Opening and Closing PHP Tags.
+	Ref: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#opening-and-closing-php-tags
+	#############################################################################
+	-->
+	<!-- Covers rule: When embedding multi-line PHP snippets within a HTML block, the
+		 PHP open and close tags must be on a line by themselves. -->
+	<rule ref="Squiz.PHP.EmbeddedPhp"/>
+	<rule ref="Squiz.PHP.EmbeddedPhp.SpacingBefore">
+		<severity>0</severity>
+	</rule>
+	<rule ref="Squiz.PHP.EmbeddedPhp.Indent">
+		<severity>0</severity>
+	</rule>
+	<rule ref="Squiz.PHP.EmbeddedPhp.OpenTagIndent">
+		<severity>0</severity>
+	</rule>
+	<rule ref="Squiz.PHP.EmbeddedPhp.SpacingAfter">
+		<severity>0</severity>
+	</rule>
+
+
+	<!--
+	#############################################################################
+	Handbook: General - No Shorthand PHP Tags.
+	Ref: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#no-shorthand-php-tags
+	#############################################################################
+	-->
+	<!-- Covers rule: Never use shorthand PHP start tags. Always use full PHP tags. -->
+	<rule ref="Generic.PHP.DisallowShortOpenTag"/>
+	<rule ref="Generic.PHP.DisallowAlternativePHPTags"/>
+
+
+	<!--
+	#############################################################################
+	Handbook: General - Single and Double Quotes.
+	Ref: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#single-and-double-quotes
+	#############################################################################
+	-->
+	<!-- Covers rule: Use single and double quotes when appropriate.
+		 If you're not evaluating anything in the string, use single quotes. -->
+	<rule ref="Squiz.Strings.DoubleQuoteUsage.NotRequired"/>
+
+	<!-- Rule: Text that goes into HTML or XML attributes should be escaped so that
+		 single or double quotes do not end the attribute value.
+		 https://github.com/WordPress/WordPress-Coding-Standards/issues/527 -->
+
+
+	<!--
+	#############################################################################
+	Handbook: General - Writing include/require statements.
+	Ref: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#writing-include-require-statements
+	#############################################################################
+	-->
+
+	<!-- Covers rule: include[_once] and require[_once] are language constructs, they do
+		 not need parentheses around the path, so those shouldn't be used. -->
+	<rule ref="PEAR.Files.IncludingFile.BracketsNotRequired"/>
+
+	<!-- Covers rule: There should only be one space between the path and the include/require keywords.
+		 Note: the sniff covers more language constructs than just include/require. While not in the handbook,
+		 WP Core already complies with this, so we may as well enforce it.  -->
+	<rule ref="Generic.WhiteSpace.LanguageConstructSpacing"/>
+
+	<!-- Covers rule: It is strongly recommended to use require[_once] for unconditional includes. -->
+	<rule ref="PEAR.Files.IncludingFile.UseRequire">
+		<type>warning</type>
+	</rule>
+	<rule ref="PEAR.Files.IncludingFile.UseRequireOnce">
+		<type>warning</type>
+	</rule>
+
+
+	<!--
+	#############################################################################
+	Handbook: Naming - Naming Conventions.
+	Ref: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#naming-conventions
+	#############################################################################
+	-->
+	<!-- Covers rule: Use lowercase letters in variable, action/filter, and function names.
+		 Separate words via underscores. -->
+	<rule ref="WordPress.NamingConventions.ValidFunctionName"/>
+	<rule ref="WordPress.NamingConventions.ValidHookName"/>
+	<rule ref="WordPress.NamingConventions.ValidVariableName"/>
+
+	<!-- Covers rule: It is _strongly recommended_ to avoid reserved keywords as function parameter names. -->
+	<rule ref="Universal.NamingConventions.NoReservedKeywordParameterNames"/>
+
+	<!-- Covers rule: Class, trait, interface, enum names should use capitalized words separated by underscores. -->
+	<rule ref="PEAR.NamingConventions.ValidClassName"/>
+
+	<!-- Covers rule: Constants should be in all upper-case with underscores separating words. -->
+	<rule ref="Generic.NamingConventions.UpperCaseConstantName"/>
+
+	<!-- Covers rule: Files should be named descriptively using lowercase letters.
+		 Hyphens should separate words. -->
+	<!-- Covers rule: Class file names should be based on the class name with "class-"
+		 prepended and the underscores in the class name replaced with hyphens. -->
+	<!-- Covers rule: Files containing template tags in wp-includes should have "-template"
+		 appended to the end of the name. -->
+	<rule ref="WordPress.Files.FileName"/>
+
+	<!-- Rule: For files containing test classes, the file name should reflect the class name exactly, as per PSR4.
+		 https://github.com/WordPress/WordPress-Coding-Standards/issues/1995 -->
+
+
+	<!--
+	#############################################################################
+	Handbook: Naming - Interpolation for Naming Dynamic Hooks.
+	Ref: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#interpolation-for-naming-dynamic-hooks
+
+	https://github.com/WordPress/WordPress-Coding-Standards/issues/751
+	#############################################################################
+	-->
+	<!-- Rule: Dynamic hooks should be named using interpolation rather than concatenation. -->
+
+	<!-- Rule: Variables used in hook tags should be wrapped in curly braces { and },
+		 with the complete outer tag name wrapped in double quotes. -->
+
+	<!-- Rule: Where possible, dynamic values in tag names should also be as succinct
+		 and to the point as possible. -->
+
+
+	<!--
+	#############################################################################
+	Handbook: Whitespace - Space Usage.
+	Ref: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#space-usage
+	#############################################################################
+	-->
+	<!-- Covers rule: Always put spaces after commas... -->
+	<!-- No space before a comma and one space or a new line after. -->
+	<rule ref="Universal.WhiteSpace.CommaSpacing"/>
+	<rule ref="Universal.WhiteSpace.CommaSpacing.TooMuchSpaceAfterCommaBeforeTrailingComment">
+		<!-- Alignment of trailing comments is allowed. -->
+		<severity>0</severity>
+	</rule>
+	<!-- Comma spacing in function declarations, including closure use statements, is handled by the
+		 Squiz.Functions.FunctionDeclarationArgumentSpacing sniff. -->
+	<rule ref="Universal.WhiteSpace.CommaSpacing.SpaceBeforeInFunctionDeclaration">
+		<severity>0</severity>
+	</rule>
+	<rule ref="Universal.WhiteSpace.CommaSpacing.TooMuchSpaceAfterInFunctionDeclaration">
+		<severity>0</severity>
+	</rule>
+	<rule ref="Universal.WhiteSpace.CommaSpacing.NoSpaceAfterInFunctionDeclaration">
+		<severity>0</severity>
+	</rule>
+	<rule ref="Universal.WhiteSpace.CommaSpacing.SpaceBeforeInClosureUse">
+		<severity>0</severity>
+	</rule>
+	<rule ref="Universal.WhiteSpace.CommaSpacing.TooMuchSpaceAfterInClosureUse">
+		<severity>0</severity>
+	</rule>
+	<rule ref="Universal.WhiteSpace.CommaSpacing.NoSpaceAfterInClosureUse">
+		<severity>0</severity>
+	</rule>
+	<!-- Comma spacing in function calls is handled by the Generic.Functions.FunctionCallArgumentSpacing sniff. -->
+	<rule ref="Universal.WhiteSpace.CommaSpacing.SpaceBeforeInFunctionCall">
+		<severity>0</severity>
+	</rule>
+	<rule ref="Universal.WhiteSpace.CommaSpacing.TooMuchSpaceAfterInFunctionCall">
+		<severity>0</severity>
+	</rule>
+	<rule ref="Universal.WhiteSpace.CommaSpacing.NoSpaceAfterInFunctionCall">
+		<severity>0</severity>
+	</rule>
+
+	<!-- Covers rule: Always put spaces ... on both sides of logical,
+		 arithmetic, comparison, string and assignment operators. -->
+	<rule ref="WordPress.WhiteSpace.OperatorSpacing"/>
+	<rule ref="Squiz.Strings.ConcatenationSpacing">
+		<properties>
+			<property name="spacing" value="1"/>
+			<property name="ignoreNewlines" value="true"/>
+		</properties>
+	</rule>
+
+	<!-- Covers rule: Put spaces on both sides of the opening and closing parentheses of control structure blocks. -->
+	<rule ref="WordPress.WhiteSpace.ControlStructureSpacing"/>
+
+	<!-- Covers rule: Define a function like so: function my_function( $param1 = 'foo', $param2 = 'bar' ) { -->
+	<rule ref="Generic.Functions.OpeningFunctionBraceKernighanRitchie">
+		<properties>
+			<property name="checkClosures" value="false"/>
+		</properties>
+	</rule>
+	<!-- Prevent duplicate message. This is now checked by the Squiz.Functions.MultiLineFunctionDeclaration sniff. -->
+	<rule ref="Generic.Functions.OpeningFunctionBraceKernighanRitchie.ContentAfterBrace">
+		<severity>0</severity>
+	</rule>
+
+	<rule ref="Squiz.Functions.MultiLineFunctionDeclaration"/>
+	<!-- WP demands brace on same line, not on the next line. Silence errors related to "brace on same line". -->
+	<rule ref="Squiz.Functions.MultiLineFunctionDeclaration.BraceOnSameLine">
+		<severity>0</severity>
+	</rule>
+	<rule ref="Squiz.Functions.MultiLineFunctionDeclaration.BraceSpacing">
+		<severity>0</severity>
+	</rule>
+	<rule ref="Squiz.Functions.MultiLineFunctionDeclaration.BraceIndent">
+		<severity>0</severity>
+	</rule>
+
+	<rule ref="Squiz.Functions.FunctionDeclarationArgumentSpacing">
+		<properties>
+			<property name="equalsSpacing" value="1"/>
+			<property name="requiredSpacesAfterOpen" value="1"/>
+			<property name="requiredSpacesBeforeClose" value="1"/>
+		</properties>
+	</rule>
+	<rule ref="Squiz.Functions.FunctionDeclarationArgumentSpacing.SpacingAfterVariadic">
+		<severity>0</severity>
+	</rule>
+
+	<!-- Covers rule: Call a function, like so: my_function( $param1, func_param( $param2 ) ); -->
+	<rule ref="PEAR.Functions.FunctionCallSignature">
+		<properties>
+			<property name="requiredSpacesAfterOpen" value="1"/>
+			<property name="requiredSpacesBeforeClose" value="1"/>
+
+			<!-- ... and for multi-line function calls, there should only be one parameter per line. -->
+			<property name="allowMultipleArguments" value="false"/>
+		</properties>
+	</rule>
+
+	<rule ref="Generic.Functions.FunctionCallArgumentSpacing"/>
+
+	<!-- Rule: Perform logical comparisons, like so: if ( ! $foo ) { -->
+
+	<!-- Covers rule: Type casts must be lowercase. Always prefer the short form
+		 of type casts, (int) instead of (integer) and (bool) rather than (boolean).
+		 For float casts use (float), not (real) which is deprecated in PHP 7.4, and removed in PHP 8. -->
+	<rule ref="Generic.Formatting.SpaceAfterCast"/>
+	<rule ref="Squiz.WhiteSpace.CastSpacing"/>
+	<rule ref="WordPress.WhiteSpace.CastStructureSpacing"/>
+	<rule ref="WordPress.PHP.TypeCasts"/>
+	<rule ref="PSR12.Keywords.ShortFormTypeKeywords"/>
+	<!-- N.B.: This sniff also checks the case of (parameter/return) type declarations, not just type casts. -->
+	<rule ref="Generic.PHP.LowerCaseType"/>
+
+	<!-- Covers rule: ... array items, only include a space around the index if it is a variable. -->
+	<rule ref="WordPress.Arrays.ArrayKeySpacingRestrictions"/>
+
+	<!-- Covers rule: In a switch block, there must be no space between the case condition and the colon. -->
+	<!-- Covered by the PSR2.ControlStructures.SwitchDeclaration sniff. -->
+
+	<!-- Covers rule: Unless otherwise specified, parentheses should have spaces inside them. -->
+	<rule ref="Generic.WhiteSpace.ArbitraryParenthesesSpacing">
+		<properties>
+			<property name="spacing" value="1"/>
+			<property name="ignoreNewlines" value="true"/>
+		</properties>
+	</rule>
+
+	<!-- Covers rule: When using increment or decrement operators, there should be
+		 no spaces between the operator and the variable it applies to. -->
+	<rule ref="Generic.WhiteSpace.IncrementDecrementSpacing"/>
+
+	<!-- Implied through the examples: Object operators should not have whitespace around them unless they are multi-line. -->
+	<rule ref="WordPress.WhiteSpace.ObjectOperatorSpacing">
+		<properties>
+			<property name="ignoreNewlines" value="true"/>
+		</properties>
+	</rule>
+
+
+	<!--
+	#############################################################################
+	Handbook: Whitespace - Indentation.
+	Ref: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#indentation
+	#############################################################################
+	-->
+	<!-- Covers rule: Your indentation should always reflect logical structure. -->
+	<rule ref="Generic.WhiteSpace.ScopeIndent">
+		<properties>
+			<property name="exact" value="false"/>
+			<property name="indent" value="4"/>
+			<property name="tabIndent" value="true"/>
+			<property name="ignoreIndentationTokens" type="array">
+				<element value="T_HEREDOC"/>
+				<element value="T_NOWDOC"/>
+				<element value="T_INLINE_HTML"/>
+			</property>
+		</properties>
+	</rule>
+	<rule ref="WordPress.Arrays.ArrayIndentation"/>
+
+	<!-- Covers rule: Use real tabs and not spaces. -->
+	<rule ref="Generic.WhiteSpace.DisallowSpaceIndent"/>
+	<rule ref="Universal.WhiteSpace.PrecisionAlignment"/>
+
+	<!-- Generic array layout check. -->
+	<!-- Covers rule: For associative arrays, each item should start on a new line
+		 when the array contains more than one item. -->
+	<rule ref="WordPress.Arrays.ArrayDeclarationSpacing"/>
+
+	<!-- Covers various array whitespace issues. -->
+	<rule ref="NormalizedArrays.Arrays.ArrayBraceSpacing">
+		<properties>
+			<property name="spacesWhenEmpty" value="0"/>
+			<property name="spacesSingleLine" value="1"/>
+			<property name="spacesMultiLine" value="newline"/>
+		</properties>
+	</rule>
+
+	<!-- Covers rule: Note the comma after the last array item: this is recommended. -->
+	<rule ref="NormalizedArrays.Arrays.CommaAfterLast"/>
+
+	<!-- Covers rule: For switch control structures, case statements should be indented one tab
+		 from the switch statement and the contents of the case should be indented one tab
+		 from the case condition statement. -->
+	<rule ref="PSR2.ControlStructures.SwitchDeclaration"/>
+	<!-- Prevent duplicate messages for the same issue. Covered by other sniffs. -->
+	<rule ref="PSR2.ControlStructures.SwitchDeclaration.NotLower">
+		<severity>0</severity>
+	</rule>
+	<rule ref="PSR2.ControlStructures.SwitchDeclaration.BreakNotNewLine">
+		<severity>0</severity>
+	</rule>
+	<rule ref="PSR2.ControlStructures.SwitchDeclaration.BodyOnNextLine">
+		<severity>0</severity>
+	</rule>
+
+	<!-- Covers rule: ... while spaces can be used mid-line for alignment. -->
+	<rule ref="Universal.WhiteSpace.DisallowInlineTabs"/>
+
+	<!-- Implied through the examples: align the assignment operator in a block of assignments. -->
+	<rule ref="Generic.Formatting.MultipleStatementAlignment">
+		<properties>
+			<property name="maxPadding" value="40"/>
+		</properties>
+	</rule>
+
+	<!-- Implied through the examples: align the double arrows. -->
+	<rule ref="WordPress.Arrays.MultipleStatementAlignment">
+		<properties>
+			<property name="maxColumn" value="60"/>
+		</properties>
+	</rule>
+
+
+	<!--
+	#############################################################################
+	Handbook: Whitespace - Remove Trailing Spaces.
+	Ref: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#remove-trailing-spaces
+	#############################################################################
+	-->
+	<!-- Covers rule: Remove trailing whitespace at the end of each line of code. -->
+	<rule ref="Squiz.WhiteSpace.SuperfluousWhitespace"/>
+
+	<!-- Covers rule: Omitting the closing PHP tag at the end of a file is preferred. -->
+	<rule ref="PSR2.Files.ClosingTag"/>
+
+	<!-- Covers rule: There should be no trailing blank lines at the end of a function body. -->
+	<rule ref="PSR2.Methods.FunctionClosingBrace"/>
+
+
+	<!--
+	#############################################################################
+	Handbook: Formatting - Brace Style.
+	Ref: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#brace-style
+	#############################################################################
+	-->
+	<!-- Covers rule: Braces shall be used for all blocks. -->
+	<rule ref="Squiz.ControlStructures.ControlSignature"/>
+
+	<!-- Covers rule: Braces should always be used, even when they are not required. -->
+	<rule ref="Generic.ControlStructures.InlineControlStructure"/>
+
+
+	<!--
+	#############################################################################
+	Handbook: Formatting - Declaring Arrays.
+	Ref: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#declaring-arrays
+	#############################################################################
+	-->
+	<!-- Covers rule: Arrays must be declared using long array syntax. -->
+	<rule ref="Universal.Arrays.DisallowShortArraySyntax"/>
+
+
+	<!--
+	#############################################################################
+	Handbook: Formatting - Multiline Function Calls.
+	Ref: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#multiline-function-calls
+	#############################################################################
+	-->
+	<!-- Covers rule: When splitting a function call over multiple lines, each parameter must be on a separate line. -->
+	<!-- Covered via PEAR.Functions.FunctionCallSignature in Space Usage section. -->
+
+	<!-- Rule: Single line inline comments can take up their own line. -->
+	<!-- Rule: Each parameter must take up no more than a single line. Multi-line parameter
+		 values must be assigned to a variable and then that variable should be passed to the function call.
+		 https://github.com/WordPress/WordPress-Coding-Standards/issues/1330 -->
+
+
+	<!--
+	#############################################################################
+	Handbook: Formatting - Type declarations.
+	Ref: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#type-declarations
+	#############################################################################
+	-->
+	<!-- Covers rule: Type declarations must have exactly one space before and after the type. -->
+	<!-- Covered by the Squiz.Functions.FunctionDeclarationArgumentSpacing sniff. -->
+
+	<!-- Covers rule: There should be no space between the nullability operator and the actual type. -->
+	<rule ref="PSR12.Functions.NullableTypeDeclaration"/>
+
+	<!-- Rule: Class/interface/enum name based type declarations should use the case of the
+		 class/interface/enum name as declared... -->
+	<!-- Not sniffable except for PHP native names and known WP class names (this last part via
+		 the WordPress.WP.ClassNameCase sniff once switched to the (upcoming/future)
+		 PHPCSUtils AbstractClassUseSniff. -->
+
+	<!-- Covers rule: ... while the keyword-based type declarations should be lowercased. -->
+	<!-- Covered by the Generic.PHP.LowerCaseType sniff. -->
+
+	<!-- Covers rule: Return type declarations should have no space between the closing parenthesis
+		 of the function declaration and the colon starting a return type. -->
+	<rule ref="PSR12.Functions.ReturnTypeDeclaration"/>
+
+	<!-- Implied through the examples: There should no space around the union or intersection type operators. -->
+	<rule ref="Universal.Operators.TypeSeparatorSpacing"/>
+
+
+	<!--
+	#############################################################################
+	Handbook: Formatting - Magic constants.
+	Ref: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#magic-constants
+	#############################################################################
+	-->
+	<!-- Covers rule: The PHP native __*__ magic constants should be written in uppercase. -->
+	<rule ref="Universal.Constants.UppercaseMagicConstants"/>
+
+	<!-- Covers rule: When using the ::class constant for class name resolution, the class keyword should be in lowercase... -->
+	<rule ref="Universal.Constants.LowercaseClassResolutionKeyword"/>
+
+	<!-- Covers rule: ... and there should be no spaces around the :: operator. -->
+	<!-- Covered by the WordPress.WhiteSpace.ObjectOperatorSpacing sniff. -->
+
+
+	<!--
+	#############################################################################
+	Handbook: Formatting - Spread operator.
+	Ref: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#spread-operator
+	#############################################################################
+	-->
+	<!-- Covers rule: When using the spread operator, there should be one space or a new line
+		 with the appropriate indentation before the spread operator. -->
+	<!-- Covered by a variety of sniffs which deal with function calls, function declarations, array declarations. -->
+
+	<!-- Covers rule: There should be no spaces between the spread operator and the variable/function call it applies to. -->
+	<rule ref="Generic.WhiteSpace.SpreadOperatorSpacingAfter"/>
+
+	<!-- Covers rule: When combining the spread operator with the reference operator (&), there should be no spaces between them.. -->
+	<!-- Covered by the Squiz.Functions.FunctionDeclarationArgumentSpacing.SpacingAfterReference error code. -->
+
+
+	<!--
+	#############################################################################
+	Handbook: Declare Statements, Namespace, and Import Statements - Namespace declarations.
+	Ref: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#namespace-declarations
+	#############################################################################
+	-->
+	<!-- Rule: Each part of a namespace name should consist of capitalized words separated by underscores.
+		 https://github.com/WordPress/WordPress-Coding-Standards/issues/2304 -->
+
+	<!-- Rule: Namespace declarations should have exactly one blank line before the declaration and at least one blank line after.
+		 https://github.com/WordPress/WordPress-Coding-Standards/issues/2305 -->
+
+	<!-- Covers rule: There should be only one namespace declaration per file... -->
+	<rule ref="Universal.Namespaces.OneDeclarationPerFile"/>
+
+	<!-- Covers rule: ... and it should be at the top of the file.
+		 Note: with only one namespace declaration, it not being at the top of the file would be a parse error. -->
+	<!-- When in the file header, covered by PSR12.Files.FileHeader.IncorrectOrder. -->
+
+	<!-- Covers rule: Namespace declarations using curly brace syntax are not allowed. -->
+	<rule ref="Universal.Namespaces.DisallowCurlyBraceSyntax"/>
+
+	<!-- Covers rule: Explicit global namespace declaration (namespace declaration without name) are also not allowed. -->
+	<rule ref="Universal.Namespaces.DisallowDeclarationWithoutName"/>
+
+
+	<!--
+	#############################################################################
+	Handbook: Declare Statements, Namespace, and Import Statements - Using import use statements.
+	Ref: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#using-import-use-statements
+	#############################################################################
+	-->
+	<!-- Covers rule: Import use statements should be at the top of the file and follow the (optional) namespace declaration. -->
+	<rule ref="PSR12.Files.FileHeader.IncorrectOrder"/>
+
+	<!-- Covers rule: Import use statements should follow a specific order based on the type of the import:
+		 1. use statements for namespaces, classes, interfaces, traits and enums
+		 2. use statements for functions
+		 3. use statements for constants -->
+	<!-- Not yet covered: use statements which are not part of the file header. -->
+	<rule ref="PSR12.Files.FileHeader.IncorrectGrouping"/>
+
+	<!-- Rule: When using aliases, make sure the aliases follow the WordPress naming convention ...
+		 https://github.com/WordPress/WordPress-Coding-Standards/issues/2306 -->
+
+	<!-- Covers rule: ... and are unique. -->
+	<rule ref="Universal.UseStatements.NoUselessAliases"/>
+
+	<!-- Covers rules: (example based rules, group use formatting, spacing around keywords) -->
+
+	<!-- Implied through the examples: There should be exactly one space before/after keywords. -->
+	<!-- Spacing after "use" keyword: covered by the Generic.WhiteSpace.LanguageConstructSpacing sniff. -->
+	<rule ref="Universal.UseStatements.KeywordSpacing"/>
+	<rule ref="Universal.UseStatements.KeywordSpacing.SpaceAfterUse">
+		<severity>0</severity>
+	</rule>
+
+	<!-- Implied through the examples: Names in an import use statement should not start with a leading backslash. -->
+	<rule ref="Universal.UseStatements.NoLeadingBackslash"/>
+
+	<!-- Implied through the examples: The use, function, const and as keywords should be lowercase.
+		 For the "use" and "as" keywords, this is covered via the Generic.PHP.LowerCaseKeyword sniff. -->
+	<rule ref="Universal.UseStatements.LowercaseFunctionConst"/>
+
+	<!-- Implied through the examples: When using group use statements, there should be one statement
+		 for each type - OO constructs (classes/interfaces/traits), functions, constants.
+		 The various types should not be combined in one group use statement. -->
+	<rule ref="Universal.UseStatements.DisallowMixedGroupUse"/>
+
+
+	<!--
+	#############################################################################
+	Handbook: Object-Oriented Programming - Only One Object Structure (Class/Interface/Trait) per File.
+	Ref: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#only-one-object-structure-class-interface-trait-per-file
+	#############################################################################
+	-->
+	<!-- Covers rule: Only One Object Structure (Class/Interface/Trait) per file. -->
+	<rule ref="Generic.Files.OneObjectStructurePerFile"/>
+
+
+	<!--
+	#############################################################################
+	Handbook: Object-Oriented Programming - Trait Use Statements.
+	Ref: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#trait-use-statements
+	#############################################################################
+	-->
+	<!-- Covers rule: Trait use statements should be at the top of a class ... -->
+	<!-- Covered by the PSR12.Traits.UseDeclaration sniff. -->
+
+	<!-- Rule: ... and should have exactly one blank line before the first use statement,
+		 and at least one blank line after the last statement.
+		 The only exception is when the class only contains trait use statements,
+		 in which case the blank line after may be omitted. -->
+	<!-- Blank line after covered by the PSR12.Traits.UseDeclaration sniff. -->
+
+	<!-- Covers rule: (example based rules: spacing, grouping and indentation). -->
+	<rule ref="PSR12.Traits.UseDeclaration"/>
+
+	<!-- Allow for a blank line between the OO statement and the first trait use statement. -->
+	<rule ref="PSR12.Traits.UseDeclaration.UseAfterBrace">
+		<severity>0</severity>
+	</rule>
+
+	<!-- Prevent duplicate messages - spacing after use is already covered by `Generic.WhiteSpace.LanguageConstructSpacing`. -->
+	<rule ref="PSR12.Traits.UseDeclaration.SpaceAfterUse">
+		<severity>0</severity>
+	</rule>
+	<!-- Prevent duplicate messages - spacing around a comma is already covered by `Universal.WhiteSpace.CommaSpacing`. -->
+	<rule ref="PSR12.Traits.UseDeclaration.SpaceBeforeComma">
+		<severity>0</severity>
+	</rule>
+	<rule ref="PSR12.Traits.UseDeclaration.SpaceAfterComma">
+		<severity>0</severity>
+	</rule>
+
+
+	<!--
+	#############################################################################
+	Handbook: Object-Oriented Programming - Visibility should always be declared.
+	Ref: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#visibility-should-always-be-declared
+	#############################################################################
+	-->
+	<!-- Covers rule: For all constructs that allow it (properties, methods, class constants since PHP 7.1),
+		 visibility should be explicitly declared.
+		 Includes "only one property declaration per statement". -->
+	<rule ref="PSR2.Classes.PropertyDeclaration"/>
+	<rule ref="PSR2.Classes.PropertyDeclaration.Underscore">
+		<severity>0</severity>
+	</rule>
+	<rule ref="Squiz.Scope.MethodScope"/>
+
+	<!-- Covers rule: Using the var keyword for property declarations is not allowed. -->
+	<!-- Covered by the PSR2.Classes.PropertyDeclaration sniff. -->
+
+
+	<!--
+	#############################################################################
+	Handbook: Object-Oriented Programming - Visibility and modifier order.
+	Ref: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#visibility-and-modifier-order
+	#############################################################################
+	-->
+	<!-- Covers rule: When using multiple modifiers for a class declaration, the order should be as follows:
+		 - First the optional abstract or final modifier.
+		 - Next, the optional readonly modifier. -->
+	<rule ref="Universal.Classes.ModifierKeywordOrder"/>
+
+	<!-- Covers rule: When using multiple modifiers for a constant declaration inside object-oriented structures,
+		 the order should be as follows:
+		 - First the optional final modifier.
+		 - Next, the visibility modifier. -->
+	<rule ref="Universal.Constants.ModifierKeywordOrder"/>
+
+	<!-- Covers rule: When using multiple modifiers for a property declaration, the order should be as follows:
+		 - First a visibility modifier.
+		 - Next, the optional static or readonly modifier (these keywords are mutually exclusive).
+		 - Finally, the optional type declaration. -->
+	<!-- Covered by the PSR2.Classes.PropertyDeclaration sniff. -->
+
+	<!-- Covers rule: When using multiple modifiers for a method declaration, the order should be as follows:
+		 - First the optional abstract or final modifier.
+		 - Then, a visibility modifier.
+		 - Finally, the optional static modifier. -->
+	<rule ref="PSR2.Methods.MethodDeclaration"/>
+	<rule ref="PSR2.Methods.MethodDeclaration.Underscore">
+		<severity>0</severity>
+	</rule>
+
+	<!-- Implied through the examples: Single space after each modifier keyword. -->
+	<rule ref="Squiz.WhiteSpace.ScopeKeywordSpacing"/>
+
+
+	<!--
+	#############################################################################
+	Handbook: Object-Oriented Programming - Object Instantiation.
+	Ref: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#object-instantiation
+	#############################################################################
+	-->
+	<!-- Covers rule: When instantiating a new object instance, parenthesis must always be used, even when not strictly necessary. -->
+	<rule ref="PSR12.Classes.ClassInstantiation"/>
+	<rule ref="Universal.Classes.RequireAnonClassParentheses"/>
+
+	<!-- Covers rule: There should be no space between the name of the class being instantiated and the opening parenthesis. -->
+	<!-- Covered by the PEAR.Functions.FunctionCallSignature sniff for non-anonymous classes. -->
+	<rule ref="Universal.WhiteSpace.AnonClassKeywordSpacing">
+		<properties>
+			<property name="spacing" value="0"/>
+		</properties>
+	</rule>
+
+
+	<!--
+	#############################################################################
+	Handbook: Control Structures - Use elseif, not else if.
+	Ref: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#use-elseif-not-else-if
+	#############################################################################
+	-->
+	<!-- Covers rule: ... use elseif for conditionals. -->
+	<rule ref="PSR2.ControlStructures.ElseIfDeclaration"/>
+
+
+	<!--
+	#############################################################################
+	Handbook: Control Structures - Yoda Conditions.
+	Ref: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#yoda-conditions
+	#############################################################################
+	-->
+	<!-- Covers rule: When doing logical comparisons involving variables, always put the variable on the right side
+		 and put constants, literals, or function calls on the left side. -->
+	<rule ref="WordPress.PHP.YodaConditions"/>
+
+	<!-- Rule: Yoda conditions for <, >, <= or >= are significantly more difficult to read
+		 and are best avoided. -->
+
+
+	<!--
+	#############################################################################
+	Handbook: Operators - Ternary Operator.
+	Ref: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#ternary-operator
+	#############################################################################
+	-->
+	<!-- Rule: Always have ternaries test if the statement is true, not false.
+		 An exception would be using ! empty(), as testing for false here is generally more intuitive.
+		 https://github.com/WordPress/WordPress-Coding-Standards/issues/643 -->
+
+	<!-- Covers rule: The short ternary operator must not be used. -->
+	<rule ref="Universal.Operators.DisallowShortTernary"/>
+
+
+	<!--
+	#############################################################################
+	Handbook: Operators - (No) Error Control Operator @.
+	Ref: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#error-control-operator
+	#############################################################################
+	-->
+	<!-- Covers rule: This operator is often used lazily instead of doing proper error checking.
+		 Its use is highly discouraged. -->
+	<rule ref="WordPress.PHP.NoSilencedErrors"/>
+
+
+	<!--
+	#############################################################################
+	Handbook: Operators - Increment/decrement operators.
+	Ref: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#increment-decrement-operators
+	#############################################################################
+	-->
+	<!-- Covers rule: Pre-increment/decrement should be favoured over post-increment/decrement
+		 for stand-alone statements. -->
+	<rule ref="Universal.Operators.DisallowStandalonePostIncrementDecrement">
+		<type>warning</type>
+	</rule>
+
+
+	<!--
+	#############################################################################
+	Handbook: Database - Database Queries.
+	Ref: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#database-queries
+	#############################################################################
+	-->
+	<!-- Covers rule: Avoid touching the database directly. -->
+	<rule ref="WordPress.DB.RestrictedFunctions"/>
+	<rule ref="WordPress.DB.RestrictedClasses"/>
+
+
+	<!--
+	#############################################################################
+	Handbook: Database - Formatting SQL statements.
+	Ref: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#formatting-sql-statements
+	#############################################################################
+	-->
+	<!-- Rule: Always capitalize the SQL parts of the statement like UPDATE or WHERE.
+		 https://github.com/WordPress/WordPress-Coding-Standards/issues/639 -->
+
+	<!-- Rule: Functions that update the database should expect their parameters to lack
+		 SQL slash escaping when passed.
+		 https://github.com/WordPress/WordPress-Coding-Standards/issues/640 -->
+
+	<!-- Covers rule: Escaping should be done as close to the time of the query
+		 as possible, preferably by using $wpdb->prepare(). -->
+	<rule ref="WordPress.DB.PreparedSQL"/>
+
+	<!-- Covers rule: in $wpdb->prepare - %s is used for string placeholders and %d is used for integer
+		 placeholders. Note that they are not 'quoted'! -->
+	<rule ref="WordPress.DB.PreparedSQLPlaceholders"/>
+
+
+	<!--
+	#############################################################################
+	Handbook: Recommendations - Self-Explanatory Flag Values for Function Arguments.
+	Ref: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#self-explanatory-flag-values-for-function-arguments
+	#############################################################################
+	-->
+
+
+	<!--
+	#############################################################################
+	Handbook: Recommendations - Clever Code.
+	Ref: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#clever-code
+	#############################################################################
+	-->
+	<!-- Covers rule: In general, readability is more important than cleverness or brevity.
+		 https://github.com/WordPress/WordPress-Coding-Standards/issues/607 -->
+	<rule ref="Squiz.PHP.DisallowMultipleAssignments"/>
+	<rule ref="Generic.Formatting.DisallowMultipleStatements"/>
+
+	<!-- Covers rule: Unless absolutely necessary, loose comparisons should not be used,
+		 as their behaviour can be misleading. -->
+	<rule phpcs-only="true" ref="Universal.Operators.StrictComparisons">
+		<type>warning</type>
+	</rule>
+	<rule ref="WordPress.PHP.StrictInArray"/>
+
+	<!-- Covers rule: Assignments must not be placed in conditionals.
+		 The "assignment in ternary" part of the sniff is currently not yet covered in
+		 the upstream version, which is why there is still a WP native sniff as well. -->
+	<rule ref="Generic.CodeAnalysis.AssignmentInCondition"/>
+	<rule ref="WordPress.CodeAnalysis.AssignmentInTernaryCondition"/>
+
+	<!-- Covers rule: In a switch statement... If a case contains a block, then falls through
+		 to the next block, this must be explicitly commented. -->
+	<!-- Covered by the PSR2.ControlStructures.SwitchDeclaration sniff. -->
+
+	<!-- Covers rule: The goto statement must never be used. -->
+	<rule ref="Generic.PHP.DiscourageGoto">
+		<type>error</type>
+		<message>The "goto" language construct should not be used.</message>
+	</rule>
+
+	<!-- Covers rule: The eval() construct is very dangerous, and is impossible to secure. ... these must not be used. -->
+	<rule ref="Squiz.PHP.Eval.Discouraged">
+		<type>error</type>
+		<message>eval() is a security risk so not allowed.</message>
+	</rule>
+
+	<!-- Covers rule: create_function() function, which internally performs an eval(),
+		 is deprecated in PHP 7.2 and has been removed in PHP 8.0. ... these must not be used. -->
+	<rule ref="WordPress.PHP.RestrictedPHPFunctions"/>
+
+
+	<!--
+	#############################################################################
+	Handbook: Recommendations - Closures.
+	Ref: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#closures-anonymous-functions
+	#############################################################################
+	-->
+	<!-- Rule: Closures should not be passed as filter or action callbacks.
+		 https://github.com/WordPress/WordPress-Coding-Standards/issues/1486 -->
+
+
+	<!--
+	#############################################################################
+	Handbook: Recommendations - Regular Expressions.
+	Ref: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#regular-expressions
+	#############################################################################
+	-->
+	<!-- Covers rule: Perl compatible regular expressions should be used in preference
+		 to their POSIX counterparts. -->
+	<rule ref="WordPress.PHP.POSIXFunctions"/>
+
+	<!-- Rule: Never use the /e switch, use preg_replace_callback instead.
+		 https://github.com/WordPress/WordPress-Coding-Standards/issues/632 -->
+
+	<!-- Covers rule: It's most convenient to use single-quoted strings for regular expressions. -->
+	<!-- Covered by the Squiz.Strings.DoubleQuoteUsage sniff. -->
+
+
+	<!--
+	#############################################################################
+	Handbook: Recommendations - Don't extract().
+	Ref: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#dont-extract
+	#############################################################################
+	-->
+	<rule ref="WordPress.PHP.DontExtract"/>
+
+
+	<!--
+	#############################################################################
+	Handbook: Recommendations - Shell commands.
+	Ref: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#shell-commands
+	#############################################################################
+	-->
+	<!-- Covers rule: Use of the backtick operator is not allowed. -->
+	<rule ref="Generic.PHP.BacktickOperator"/>
+
+
+	<!--
+	#############################################################################
+	Not in the handbook: Generic sniffs.
+	#############################################################################
+	-->
+	<!-- Important to prevent issues with content being sent before headers. -->
+	<rule ref="Generic.Files.ByteOrderMark"/>
+
+	<!-- Always have a lowertag PHP open tag. -->
+	<rule ref="Universal.PHP.LowercasePHPTag"/>
+
+	<!-- All line endings should be \n. -->
+	<rule ref="Generic.Files.LineEndings">
+		<properties>
+			<property name="eolChar" value="\n"/>
+		</properties>
+	</rule>
+
+	<!-- All files should end with a new line, but only one. -->
+	<rule ref="PSR2.Files.EndFileNewline"/>
+
+	<!-- No whitespace should come before semicolons. -->
+	<rule ref="Squiz.WhiteSpace.SemicolonSpacing"/>
+
+	<!-- There should be no empty statements, i.e. lone semi-colons or open/close tags without content. -->
+	<rule ref="Generic.CodeAnalysis.EmptyPHPStatement"/>
+
+	<!-- Lowercase PHP constants, like true, false and null. -->
+	<!-- https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#naming-conventions -->
+	<rule ref="Generic.PHP.LowerCaseConstant"/>
+
+	<!-- Lowercase PHP keywords, like class, function and case. -->
+	<rule ref="Generic.PHP.LowerCaseKeyword"/>
+
+	<!-- Class opening braces should be on the same line as the statement. -->
+	<rule ref="Generic.Classes.OpeningBraceSameLine"/>
+
+	<!-- Implied via examples: one space after keywords in class declaration, class declaration on one line,
+		 close brace on line by itself and no blank lines between OO structure body and close brace. -->
+	<rule ref="PSR2.Classes.ClassDeclaration"/>
+	<rule ref="PSR2.Classes.ClassDeclaration.OpenBraceNewLine">
+		<!-- WP expects open brace on same line as class keyword. -->
+		<severity>0</severity>
+	</rule>
+	<rule ref="PSR2.Classes.ClassDeclaration.OpenBraceWrongLine">
+		<!-- WP expects open brace on same line as class keyword. -->
+		<severity>0</severity>
+	</rule>
+
+	<!-- References to self in a class should be lower-case and not have extraneous spaces,
+		 per implicit conventions in the core codebase; the NotUsed code refers to using the
+		 fully-qualified class name instead of self, for which there are instances in core. -->
+	<rule ref="Squiz.Classes.SelfMemberReference"/>
+	<rule ref="Squiz.Classes.SelfMemberReference.NotUsed">
+		<severity>0</severity>
+	</rule>
+
+	<!-- Error on merge conflict markers. -->
+	<rule ref="Generic.VersionControl.GitMergeConflict"/>
+
+	<!--
+	#############################################################################
+	Not in the coding standard handbook: WP specific sniffs.
+	Ref: https://make.wordpress.org/core/handbook/best-practices/internationalization/ (limited info)
+	Ref: https://developer.wordpress.org/plugins/internationalization/ (more extensive)
+	#############################################################################
+	-->
+	<!-- Check for correct usage of the WP i18n functions. -->
+	<rule ref="WordPress.WP.I18n"/>
+
+	<!-- Check for correct spelling of WordPress. -->
+	<rule ref="WordPress.WP.CapitalPDangit"/>
+
+	<!-- Use the appropriate DateTime functions.
+		 See: https://github.com/WordPress/WordPress-Coding-Standards/issues/1713 -->
+	<rule ref="WordPress.DateTime.RestrictedFunctions"/>
+
+	<!-- Don't use current_time() to retrieve a timestamp. -->
+	<rule ref="WordPress.DateTime.CurrentTimeTimestamp"/>
+
+	<!-- Check that class name references use the correct case. -->
+	<rule ref="WordPress.WP.ClassNameCase"/>
+
+	<!-- Check that __DIR__ is favoured over dirname(__FILE__)
+		 and that dirname( __DIR__, $levels ) is favoured over nested calls to dirname().
+		 See: https://core.trac.wordpress.org/ticket/48082 -->
+	<rule ref="Modernize.FunctionCalls.Dirname"/>
+
+</ruleset>