Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
1 task
Tobias-Keller opened this issue Mar 24, 2022 · 20 comments

Comments

@Tobias-Keller
Copy link

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
Copy link
Member

jrfnl commented Mar 24, 2022

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
Copy link

clintonb commented May 10, 2022

@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: squizlabs/PHP_CodeSniffer#3110 (comment).

@jrfnl
Copy link
Member

jrfnl commented May 10, 2022

@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
Copy link

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
Copy link
Member

jrfnl commented Jul 9, 2022

@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
Copy link

smccafferty commented Oct 24, 2022

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
Copy link
Member

jrfnl commented Oct 25, 2022

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
Copy link

matthewmcvickar commented Nov 23, 2022

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 &#38; is an escaped & (ampersand); the & character must be escaped in XML documents.)

GaryJones added a commit to Automattic/VIP-Coding-Standards that referenced this issue Jan 30, 2023
PHP 8.1 increased the strictness of types used with native functions, and this meant WPCS 2.3.0 had a bug: WordPress/WordPress-Coding-Standards#2035

For the VIPCS ruleset tests with PHP 8.1 or above it would skip over a bunch of lines, and mark other lines as expecting errors or warnings incorrectly.

Running:

```
vendor/squizlabs/php_codesniffer/bin/phpcs --standard=WordPressVIPMinimum --severity=1 WordPressVIPMinimum/ruleset-test.inc -s
```

...shows all the expected violations, but also this for line 1:

> 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 .../vipcs/vendor/wp-coding-standards/wpcs/WordPress/Sniff.php on line 1144 (Internal.Exception)

Line 1144 relate to the retrieval of the `minimum_supported_wp_version` config value. Since it appeared to be coming through as null, the RulesetTest.php now includes setting this as a command-line argument when PHPCS is called to run the ruleset test.

When WPCS 3.0 is the minimum supported, these changes can be reverted.
GaryJones added a commit to Automattic/VIP-Coding-Standards that referenced this issue Jan 30, 2023
PHP 8.1 increased the strictness of types used with native functions, and this meant WPCS 2.3.0 had a bug: WordPress/WordPress-Coding-Standards#2035

For the VIPCS coding standards check with PHP 8.1 or above it would report incorrect violations from sniffs that included the retrieval of optional command-line arguments. These violations did not appear when running PHPCS with PHP 8.0 or below.

Since the retrieval of the optional command-line arguments appeared to be coming through as null, causing the problems, the command to run PHPCS on the VIPCS codebase now includes setting of several command-line arguments.

With the `prefixes` enabled, extra sniff behaviour is enabled, and VIPCS has no need to adhere to consistent prefixes (unlike actual WordPress plugin and theme codebases). As such, the PrefixAllGlobals rule is excluded for VIPCS.

When WPCS 3.0 is the minimum supported, these changes can be reverted.
rebeccahum added a commit to Automattic/VIP-Coding-Standards that referenced this issue Jan 31, 2023
* Ruleset tests: Add label before test runs

Make it clear which ruleset being tested, even on a test failure.

* Ruleset Tests: Work around WPCS trim() bug

PHP 8.1 increased the strictness of types used with native functions, and this meant WPCS 2.3.0 had a bug: WordPress/WordPress-Coding-Standards#2035

For the VIPCS ruleset tests with PHP 8.1 or above it would skip over a bunch of lines, and mark other lines as expecting errors or warnings incorrectly.

Running:

```
vendor/squizlabs/php_codesniffer/bin/phpcs --standard=WordPressVIPMinimum --severity=1 WordPressVIPMinimum/ruleset-test.inc -s
```

...shows all the expected violations, but also this for line 1:

> 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 .../vipcs/vendor/wp-coding-standards/wpcs/WordPress/Sniff.php on line 1144 (Internal.Exception)

Line 1144 relate to the retrieval of the `minimum_supported_wp_version` config value. Since it appeared to be coming through as null, the RulesetTest.php now includes setting this as a command-line argument when PHPCS is called to run the ruleset test.

When WPCS 3.0 is the minimum supported, these changes can be reverted.

* CS: Work around WPCS trim() bug

PHP 8.1 increased the strictness of types used with native functions, and this meant WPCS 2.3.0 had a bug: WordPress/WordPress-Coding-Standards#2035

For the VIPCS coding standards check with PHP 8.1 or above it would report incorrect violations from sniffs that included the retrieval of optional command-line arguments. These violations did not appear when running PHPCS with PHP 8.0 or below.

Since the retrieval of the optional command-line arguments appeared to be coming through as null, causing the problems, the command to run PHPCS on the VIPCS codebase now includes setting of several command-line arguments.

With the `prefixes` enabled, extra sniff behaviour is enabled, and VIPCS has no need to adhere to consistent prefixes (unlike actual WordPress plugin and theme codebases). As such, the PrefixAllGlobals rule is excluded for VIPCS.

When WPCS 3.0 is the minimum supported, these changes can be reverted.

* Unit tests: Fix PHPUnit deprecation

When running the unit tests with PHP 8.1 or above, PHPUnit would give a deprecation notice:

> PHP Deprecated:  strlen(): Passing null to parameter #1 ($string) of type string is deprecated in .../vipcs/vendor/phpunit/phpunit/src/Util/Getopt.php on line 159

The tests still ran successfully though.

This notice originated from the use of `--filter WordPressVIPMinimum`, and was fixed by adding an equals sign: `--filter=WordPressVIPMinimum`.

Under both versions, the same number of tests and test files and unique error codes were created.

---------

Co-authored-by: Rebecca Hum <[email protected]>
@philhoyt
Copy link

philhoyt commented Jun 8, 2023

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
Copy link

SH4LIN commented Jun 9, 2023

I am getting the same error.

@code-nv
Copy link

code-nv commented Jun 14, 2023

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

@philhoyt
Copy link

philhoyt commented Jun 14, 2023

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
Copy link

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
Copy link

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

@jrfnl jrfnl added this to the 3.0.0 milestone Jul 4, 2023
@Jorgu5
Copy link

Jorgu5 commented Jul 18, 2023

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 &#38; is an escaped & (ampersand); the & character must be escaped in XML documents.)

Working solution on m2 pro and PHP 8.1

@tuberb
Copy link

tuberb commented Nov 1, 2023

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
Copy link
Member

jrfnl commented Nov 1, 2023

@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.

@jrfnl jrfnl reopened this Nov 1, 2023
@jrfnl jrfnl closed this as completed Nov 1, 2023
@tuberb
Copy link

tuberb commented Nov 1, 2023

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
Copy link
Member

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
Copy link
Member

jrfnl commented Nov 1, 2023

@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.

@WordPress WordPress locked as resolved and limited conversation to collaborators Nov 1, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests