Uncaught PHP_CodeSniffer\Exceptions\RuntimeException: trim(): Passing null to parameter #1 ($string)

[Tobias-Keller]

Bug Description

When i want run the phpcbf i get the following error: PHP Fatal error: Uncaught PHP_CodeSniffer\Exceptions\RuntimeException: trim(): Passing null to parameter #1 ($string) of type string is deprecated in /somePath/vendor/wp-coding-standards/wpcs/WordPress/Sniffs/NamingConventions/PrefixAllGlobalsSniff.php on line 280

Minimal Code Snippet

The issue happens when running this command:

vendor/bin/phpcbf --standard=WordPress someFilePath.php

... over a file containing this code:

// All PHP Code Files

Error Code

PHP Fatal error: Uncaught PHP_CodeSniffer\Exceptions\RuntimeException: trim(): Passing null to parameter #1 ($string) of type string is deprecated in /somePath/vendor/wp-coding-standards/wpcs/WordPress/Sniffs/NamingConventions/PrefixAllGlobalsSniff.php on line 280

Environment

Question	Answer
PHP version	PHP 8.1.4 (cli)
PHP_CodeSniffer version	PHP_CodeSniffer version 3.6.2
WPCS version	2.3.0
WPCS install type	Composer project local

Additional Context (optional)

Tested Against develop branch?

• [ ] I have verified the issue still exists in the develop branch of WPCS.

[jrfnl]

This has already been fixed long ago in develop. The last WPCS release does not support PHP 8.0 or 8.1. Either run it on PHP < 8.0 or use develop for the time being until the next release.

[clintonb]

@jrfnl what is the release cadence/when can we expect a new release? I'm encountering the same issue, but would like to know when I can stop using the develop branch?

Also, the recommendation to use develop seems to conflict with this recommendation to not use develop: https://github.com/squizlabs/PHP_CodeSniffer/issues/3110#issuecomment-690587432.

[jrfnl]

@jrfnl what is the release cadence/when can we expect a new release? I'm encountering the same issue, but would like to know when I can stop using the develop branch?

@clintonb "When it's ready". Either run PHPCS on PHP < 8.0 or use develop for now if you must run it on PHP 8.0+.

Work on the 3.0.0 release is currently actively ongoing, but I'm not making any promises for release dates.

Also, the recommendation to use develop seems to conflict with this recommendation to not use develop: squizlabs/PHP_CodeSniffer#3110 (comment).

That was in response to a different question, different issue.

[smileBeda]

In which case all users who run latest composer will run into PHP Fatal error: Composer detected issues in your platform: Your Composer dependencies require a PHP version ">= 8.1.0". You are running 7.4.30. in .../.composer/vendor/composer/platform_check.php on line 24

Is there any way to resolve that easily?

Thank you!

[jrfnl]

@smileBeda The platform check is triggered by one of your other dependencies, not by WPCS, Nothing to do with the latest Composer either, Composer has contained a platform check for a long time.

You could run Composer with --ignore-platform-reqs=php to get round it, but again: you'd be getting round a requirement of one of your other dependencies. This is unrelated to WPCS.

[smccafferty]

Leaving this for others that have went searching for this error.

Looking at the error, this is due to a deprecation message getting bubbled up. While it is a workaround, if the error reporting level is set to ignore deprecated messages, it will no longer display throw this error. For instance phpcs -d error_reporting=24575 would execute PHPCS with error_reporting = E_ALL & ~E_DEPRECATED

[jrfnl]

As the values of the E_* constants can vary depending on the PHP version used, better to use phpcs -d error_reporting="E_ALL&~E_DEPRECATED"

[matthewmcvickar]

As the values of the E_* constants can vary depending on the PHP version used, better to use phpcs -d error_reporting="E_ALL&~E_DEPRECATED"

To apply this flag in a phpcs.xml configuration file rather than on the command line, you'd want to add the following:

<!--
Prevent errors caused by WordPress Coding Standards not supporting PHP 8.0+.
See https://github.com/WordPress/WordPress-Coding-Standards/issues/2035
-->
<ini name="error_reporting" value="E_ALL &#38; ~E_DEPRECATED" />

(Note that the & is an escaped & (ampersand); the & character must be escaped in XML documents.)

[philhoyt]

The year is 2023, I have installed the WordPress Coding Standards on a fresh install... and I am still getting this error. I find this issue every time I wipe my Macbook...

edit: mind you, I end up solving this by installing PHP 7.4 on my machine. probably not the correct answer, but at least it's working.

[SH4LIN]

I am getting the same error.

[code-nv]

getting the same error, unable to install php < 8 because the older versions are no longer supported

[philhoyt]

getting the same error, unable to install php < 8 because the older versions are no longer supported

I think I just followed the first third of this tutorial, swapping out for 7.4 https://tecadmin.net/install-php-macos/ As mentioned previously idk if this is a good solution, but it works.

Others have suggested modifying your phpcs.xml file, but I don't install the coding standards on a per-project basis, and idk how to modify this globally so PHP 7.4 it is!!!

[Nic-Sevic]

I was also running into this error with php 8.2 but setting my homebrew linked version to 8.0 resolved the error. No need to download 7.4 it seems

[yssambare12]

Still getting the same error on my MacBook with php 8.2.

[Jorgu5]

As the values of the E_* constants can vary depending on the PHP version used, better to use phpcs -d error_reporting="E_ALL&~E_DEPRECATED"

To apply this flag in a phpcs.xml configuration file rather than on the command line, you'd want to add the following:

<!--
Prevent errors caused by WordPress Coding Standards not supporting PHP 8.0+.
See https://github.com/WordPress/WordPress-Coding-Standards/issues/2035
-->
<ini name="error_reporting" value="E_ALL &#38; ~E_DEPRECATED" />

(Note that the & is an escaped & (ampersand); the & character must be escaped in XML documents.)

Working solution on m2 pro and PHP 8.1

[tuberb]

I am getting the same error with PHP 7.4 on Centos 7, and have tried all of the solutions listed above, none of which work.

PHP Fatal error: Uncaught PHP_CodeSniffer\Exceptions\RuntimeException: fclose() expects parameter 1 to be resource, bool given in /vendor/squizlabs/php_codesniffer/src/Util/Common.php on line 69 in /vendor/squizlabs/php_codesniffer/src/Runner.php:608

Could someone please list the necessary steps to get a working version of this installed from scratch, assuming that is possible?

This would be a very useful tool if I could ever get it going.

Thanks.

[jrfnl]

@tuberb The README has all the instructions to set up from scratch. Without more information, there is nothing else I can advise you.

P.S.: don't pollute old and unrelated closed issues.

[tuberb]

Not helpful. I tried to follow the readme, which did not take into account the comments above about using the develop branch. And the readme says to start with "composer config allow-plugins.dealerdirect/phpcodesniffer-composer-installer true" and I got this error " File "./composer.json" cannot be found in the current directory". So I reversed the order of the installation commands and added a require command about the develop branch and still got the error I reported.

Instead of complaining about the "pollution" of issues, it would be more helpful to be able to point people to installation instructions that actually work.

[GaryJones]

If you haven't yet got a composer.json file, then you can run composer init.

While that step is not included in our instructions, it's assumed that someone who would be at the point of using Composer to install a set of packages would understand how to create a composer.json file, or more likely already has one for their project. It's the same reason we don't say how to install Composer or a PHP binary as well (Composer and PHP are listed as Minimum Requirements).

[jrfnl]

@tuberb There is absolutely no need to use the develop branch anymore. The advice above in this issue is outdated as WPCS 3.0 has been released. Which is exactly the kind of thing why you should not be commenting on old and unrelated tickets.