From b38ae04492e53390cfcb1f3490385e205a74ff65 Mon Sep 17 00:00:00 2001
From: Paul Kevan <paul.kevan@automattic.com>
Date: Thu, 23 May 2024 10:14:01 +0100
Subject: [PATCH] Revert "more phpcs"

This reverts commit b2ca511a
---
 phpcs.xml.dist | 109 +++++++++++++++----------------------------------
 1 file changed, 33 insertions(+), 76 deletions(-)

diff --git a/phpcs.xml.dist b/phpcs.xml.dist
index 94d3f74..5f98c99 100644
--- a/phpcs.xml.dist
+++ b/phpcs.xml.dist
@@ -1,84 +1,32 @@
 <?xml version="1.0" ?>
 <ruleset name="WordCamp.org Coding Standards">
-	<description>Apply customized version of WordPress Coding Standards to WordCamp.org PHP scripts.</description>
+	<description>Apply customized version of WordPress Coding Standards to WordCamp.org projects.</description>
 
 	<!--
 		Setup instructions:
 
-		1) Install PHPCS (e.g., `brew install homebrew/php/php-code-sniffer`)
-		2) Install the WP Coding Standards (https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards)
-		3) Edit CodeSniffer.conf and update `installed_paths` to point to where you installed the WP Coding Standards,
-		   and any other tweaks you want to make.
-		   See https://github.com/iandunn/dotfiles/blob/master/phpcs/CodeSniffer.conf for an example.
-		4) Make sure this file is at the project root. You can symlink it there if your `meta.(git|svn).wordpress.org`
-		   checkout is elsewhere.
-		5) `cd` to a folder inside the project and run `phpcs`. You can use the `-a` flag to run it interactively.
-		6) Run it before you generate a patch or create a commit. Setting up a git pre-commit or pre-push hook can
-		   make that automatic.
-
-		Note: It's possible to create a `phpcs.xml` file if you want to override anything here, but please make sure
-		any code you contribute conforms to this file. If you think any of the rules here should change, start a
-		discussion in #meta-wordcamp.
+		1) Install PHPCS & all required code standards using `composer install`
+		2) Run `composer run phpcs`. You can use the `-a` flag to run it interactively.
 
 		See these links for useful information:
 			- https://github.com/squizlabs/PHP_CodeSniffer/wiki/Annotated-ruleset.xml
 			- https://github.com/squizlabs/PHP_CodeSniffer/wiki/Customisable-Sniff-Properties
-	        - https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards/wiki/Customizable-sniff-properties
+			- https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards/wiki/Customizable-sniff-properties
 	-->
 
-	<!-- TODO
-		Exclude 3rd party plugins/themes so this can be run from the project root without a ton of extraneous stuff
-		<exclude-pattern>/build/*</exclude-pattern>
-
-		disable WordPress.VIP.PostsPerPage.posts_per_page_posts_per_page for bin folder only
-			should that be `WordPress.VIP.PostsPerPage.posts_per_page` ?
-
-		Look through `General` and `Squiz` sniffs for anything you might want to add.
-			Is there one that detects `\Foo` instead of `use Foo`?
-			maximum nesting level?
-			function length?
-			unnecessary order-of-operations params, e.g., $foo = ( $bar || $qax ) ? 'bax' : 'quix';
-			echoing html instead of breaking php or using an external view. e.g., echo '<div>foo</div>'; should be `?> <div>foo</div> <?php` (but on multiple lines of course)
-			heredoc/nowdoc should never be used
-			var assignment immediately followed by if/while/for statement, without a blank space inbetween. maybe not in all cases, though?
-			closing divs with a comment after them. it adds clutter. when viewing source, this is an artifact from the days before browser dev tools. view in IDEs, this isn't necessary if the code is properly formatted.
-			return statement at end of function w/out blank line above it
-			no space between last @param and the @return in docblock. i know diff than core, but whitespace makes it easier to scan/read. should also have space above first @param. sometimes want no space between different types of tags, though.
-			opening/closing <?php ?> tags without a blank line after/before them, except when doing single-line like <?php foo(); ?>
-			align ? and : in multiple ternary operator statements
-			don't un-align params in function calls - e.g., multiple add_meta_box( $a, $b, $c, $d, $e, $f, $g ) calls should have the params aligned.
-			file missing `defined WPINC or die` at start
-			don't add `@return void`, just leave return empty
-			no space before ++,etc operators: e.g., `$attempt_count ++;`
-			replace explicit references to central.wordcamp.org / ID `5` with `is_main_site()` or `get_main_site_id()`
-			anonymous functions used with add_(action|filter), and maybe other places can detect w/out false positives. don't be lazy. should only be used with cases like array_filter.
-			whitespace-only changes to lines that don't have logic changes, in a commit that does have logic changes. this indicates that a commit is mixing coding standards changes w/ logic changes, which adds diff noise to the logic change. they should be separate commits.
-			unnecessary parenthesis in ternary conditions: $result = ( $condition ) ? 'foo' : 'bar'
-
-		Maybe add WordCamp\Remote_CSS\output_cached_css and wcorg_json_encode_attr_i18n to customEscapingFunctions or whichever param is most appropriate
-		Maybe do something similar for set_cache_headers and nonce verification
-
-		Setup WordPress.WP.I18n text_domain property and test that it works, see https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards/wiki/Customizable-sniff-properties#internationalization-setting-your-text-domain
-
-		Don't add @package phpDoc? Clutters code without adding any real value. You know what "package" the file is part of because of the folder it's in; e.g., wp-content/plugins/wordcamp-payments
-
-		Don't mush HTML elements together on the same line, unless it's really short. `<h1>The title</h1>` is ok, but `<h1><?php echo esc_html( get_the_title() ); ?></h1>` should have the h1 tags on separate lines.
-
-		wp_enqueue_*() cachebusters should use filemtime() rather than a hardcoded int.
-
-		Combine similar `use` statements on the same line. Like, all the core PHP objects, then all the WP objects on the 2nd line, then our custom objects on the 3rd line, etc.
-
-		Prevent blank lines at start of function/class
-	-->
-
-	<!-- Show sniff codes in all reports -->
-	<arg value="ps" />
-	<arg name="colors" />
-
 	<!-- Exclude 3rd-party files -->
 	<exclude-pattern>*/vendor/*</exclude-pattern>
 	<exclude-pattern>*/node_modules/*</exclude-pattern>
-	<exclude-pattern>./public_html/mu/*</exclude-pattern>
+
+	<!-- Exclude the wporg parent theme (for this project) -->
+	<exclude-pattern>/themes/pub/wporg</exclude-pattern>
+
+	<!-- Exclude all plugins except our pledge plugin -->
+	<exclude-pattern>/plugins/(?!wporg-5ftf)</exclude-pattern>
+
+	<!-- Show sniff codes in all reports -->
+	<arg value="ps" />
+	<arg name="colors" />
 
 	<!-- Scan all (php) files in the current folder and subfolders -->
 	<file>.</file>
@@ -95,9 +43,6 @@
 		<!-- It's often obvious what the placeholder is, so whether or not to include a comment is a judgement call. -->
 		<exclude name="WordPress.WP.I18n.MissingTranslatorsComment" />
 
-		<!-- Workaround for https://github.com/WordPress/WordPress-Coding-Standards/issues/1244 -->
-		<exclude name="WordPress.WP.DeprecatedFunctions.get_settingsFound" />
-
 		<!-- I know it's a language construct, but it just looks better using the function call syntax. -->
 		<exclude name="PEAR.Files.IncludingFile.BracketsNotRequired" />
 
@@ -119,6 +64,7 @@
 		<exclude name="WordPress.Arrays.ArrayDeclarationSpacing.ArrayItemNoNewLine" />
 		<exclude name="PEAR.Functions.FunctionCallSignature.ContentAfterOpenBracket" />
 		<exclude name="PEAR.Functions.FunctionCallSignature.CloseBracketLine" />
+		<exclude name="PEAR.Functions.FunctionCallSignature.MultipleArguments" />
 
 		<!--
 		 ... In multidimensional arrays, items in the child arrays should be aligned, but the parent arrays should
@@ -129,21 +75,17 @@
 		 -->
 		<rule ref="WordPress.Arrays.MultipleStatementAlignment">
 			<properties>
+				<!-- Don't align multi-line items if ALL items in the array are multi-line. -->
 				<property name="alignMultilineItems" value="!=100"/>
+				<!-- Array assignment operator should always be on the same line as the array key. -->
+				<property name="ignoreNewlines" value="false"/>
 			</properties>
 		</rule>
 
-		<!-- @todo This is temporary until the above version works. -->
-		<exclude name="WordPress.Arrays.MultipleStatementAlignment.DoubleArrowNotAligned" />
-
 		<!-- Warn about mis-aligned array items, but don't automatically "fix" them, because arrays in function calls get extra lines added.
 		     See https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards/issues/1305 -->
 		<exclude phpcbf-only="true" name="PEAR.Functions.FunctionCallSignature" />
 
-		<!-- The <?php and ?> tags can't be on a line by itself inside a <textarea>, otherwise it'll add whitespace to the content. -->
-		<exclude name="Squiz.PHP.EmbeddedPhp.ContentBeforeOpen" />
-		<exclude name="Squiz.PHP.EmbeddedPhp.ContentAfterEnd"   />
-
 		<!-- trigger_error() isn't only development function. In development environments it conveniently displays an error, but in
 		     (properly configured) production environment, it logs the error instead. -->
 		<exclude name="WordPress.PHP.DevelopmentFunctions.error_log_trigger_error" />
@@ -152,6 +94,13 @@
 		<exclude name="WordPress.PHP.DevelopmentFunctions.error_log_print_r" />
 	</rule>
 
+	<!-- Ignore the CPT template filename, since it is based on the CPT name, and can't change. -->
+	<rule ref="WordPress.Files.FileName.NotHyphenatedLowercase">
+		<exclude-pattern>*/template-parts/content-5ftf_pledge.php$</exclude-pattern>
+		<exclude-pattern>*/archive-5ftf_pledge.php$</exclude-pattern>
+		<exclude-pattern>*/single-5ftf_pledge.php$</exclude-pattern>
+	</rule>
+
 	<rule ref="WordPress-Docs">
 		<!-- If files/variables are given descriptive names like they should be, then an explicit description is usually unnecessary, so leave this as a judgement call. -->
 		<exclude name="Squiz.Commenting.FunctionComment.MissingParamComment" />
@@ -189,4 +138,12 @@
 		<!-- I think it's better to have all the `use` statements come right after the namespace line. -->
 		<exclude name="PSR2.Namespaces.NamespaceDeclaration.BlankLineAfter" />
 	</rule>
+	
+	<!-- Verify that the text_domain is set to the desired text-domain. Multiple valid text domains can be
+	     provided as a comma-delimited list. -->
+	<rule ref="WordPress.WP.I18n">
+		<properties>
+			<property name="text_domain" type="array" value="wporg-5ftf" />
+		</properties>
+	</rule>
 </ruleset>