Updates WordPress Coding Standards

composer.json

@@ -146,7 +146,7 @@
     "dealerdirect/phpcodesniffer-composer-installer": "^0.7.2",
     "roave/security-advisories": "dev-latest",
     "squizlabs/php_codesniffer": "^3.6.2",
-    "wp-coding-standards/wpcs": "^2.3"
+    "wp-coding-standards/wpcs": "dev-develop"
   },
   "config": {
     "optimize-autoloader": true,
@@ -210,6 +210,9 @@
       "MitComposerScripts::multidev_clone_syntax",
       "MitComposerScripts::multidev_search_replace_syntax"
     ],
+    "phpcs": [
+      "phpcs"
+    ],
     "pre-install-cmd": [
       "php -v"
     ],

docs/howto/normalize-code-formating.md

@@ -0,0 +1,34 @@
+# How to normalize code formating
+
+This respostory uses `phpcs` to scan for both security and formating preferences. It follows the WordPress Coding
+Standards as well as other PHP standards where they don't conflict.
+
+## CodeClimate runs on all Pull Requests
+
+We have configure CodeClimate to check for PHPCS violations using the rules we have defined in `phpcs.xml` on every
+pull request. When possible, issues flagged in this way should be resolved prior to asking for a Code Review. If you do
+no feel it is important to resolve a particular issue, it would be best to note that to the code reviewer when requsting
+a code review and why.
+
+## Security checks run in GitHub Actions
+
+We run a subset of phpcs rules automatically in GitHub Actions. Failure on these checks will fail the build. If there is
+a good reason to not resolve something found in this check, you will need to:
+
+- use the phpcs:disable/enable syntax for the specific rule to be skipped around the code in violation
+- inform the code reviewer clearly why this is being skipped and not resolved at this time
+
+## Running checks locally
+
+It is often better to run checks locally rather than rely on CodeClimate or GitHub Actions to determine if you have
+resolved all issues in a pull reqeust.
+
+You can run `composer security` to run the security checks on the whole repository. This should always be expected to
+output no concerns.
+
+You can run our full checks on a specific file via `composer phpcs FILENAME` (you can run it on the whole repository
+but there are a lot of legacy rule violations so you should focus only on files you are working directly with as part
+of your pull request).
+
+You can enable your code editor to work for you. In VSCode, the extension `PHP Sniffer & Beatifier` does solid job
+autofixing or flagging errors when you save the file depending on your configuration.

phpcs.security.xml

@@ -10,7 +10,7 @@
     <exclude name="PSR2" />
     <exclude name="Squiz" />
     <exclude name="WordPress.Arrays" />
-    <exclude name="WordPress.Classes" />
+    <!-- <exclude name="WordPress.Classes" /> -->
     <exclude name="WordPress.CodeAnalysis" />
     <exclude name="WordPress.DateTime" />
     <exclude name="WordPress.DB" />
@@ -20,5 +20,7 @@
     <exclude name="WordPress.Utils" />
     <exclude name="WordPress.WP" />
     <exclude name="WordPress.WhiteSpace" />
+    <exclude name="Universal.WhiteSpace.DisallowInlineTabs.NonIndentTabsUsed" />
+    <exclude name="Universal.ControlStructures.DisallowLonelyIf.Found" />
   </rule>
 </ruleset>

web/app/plugins/mitlib-pull-hours/src/class-display-widget-slim.php

@@ -124,7 +124,7 @@ public function widget( $args, $instance ) {
 
 		// Render markup.
 		echo wp_kses( $args['before_widget'], $allowed );
-		$template = file_get_contents( dirname( __FILE__ ) . '/../templates/display-widget-slim.html' );
+		$template = file_get_contents( __DIR__ . '/../templates/display-widget-slim.html' );
 		echo wp_kses( sprintf( $template, $instance['location_label'], $instance['title'] ), $allowed );
 		echo wp_kses( $args['after_widget'], $allowed );
 	}