Ensure Compatibility with PHP 8.0 and 8.1

[kevinfodness]

In preparation for upgrading environments to use PHP 8.0 and 8.1, ensure these coding standards and their dependencies do not throw deprecation warnings or any other unexpected output when used in an environment that is set to PHP 8.0 or 8.1.

For example:

An error occurred during processing; checking has been aborted. The error message was: trim(): Passing null to parameter #1 ($string) of type string is deprecated in ~/vendor/wp-coding-standards/wpcs/WordPress/Sniffs/NamingConventions/PrefixAllGlobalsSniff.php on line 280phpcs

(Note that the above may have already been fixed in this repo by bumping dependency versions, but we need to validate this)

[srtfisher]

Following along to this note, PHP 8.0 is supported mostly but 8.1 does not pass at all. The latest version of https://github.com/WordPress/WordPress-Coding-Standards/ (2.3) fails terribly with that error message you noted: WordPress/WordPress-Coding-Standards#2035

Hopefully, we'll be getting a 3.0 soon: WordPress/WordPress-Coding-Standards#1877

[emilyatmobtown]

WPCS is failing when it checks for a runtime value for prefixes and text_domain. When it does this a null value is passed to trim() which triggers a deprecation warning in PHP 8.1. This results in false phpcs errors.

An interim workaround is to set runtime values for prefixes and text_domain until the update is released.

[kevinfodness]

Alternately, we could modify the README to indicate that users should define these values in their config when using this standard (which we are already doing internally, but could formalize this expectation within this package).

[emilyatmobtown]

@kevinfodness To clarify, setting the values in the ruleset (ours or the user's) doesn't address the bug. The values must be set on the command line with --runtime-set text_domain <domain> --runtime-set prefixes <prefixes>, whether or not they're also set in the ruleset. This differs from our internal approach, but I agree we can include it in the README as a necessary workaround for 8.1 support until WPCS releases their fix.

[kevinfodness]

Ah, yes, that is an issue then. Thanks for flagging!

[srtfisher]

#30 will fix this with documentation. We'll need to wait for the full wp-coding-standards/wpcs 3.0 release to fully fix this. The timing on that is unclear at the moment: WordPress/WordPress-Coding-Standards#1877