-
-
Notifications
You must be signed in to change notification settings - Fork 490
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
Comments
This has already been fixed long ago in |
@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 |
@clintonb "When it's ready". Either run PHPCS on PHP < 8.0 or use Work on the 3.0.0 release is currently actively ongoing, but I'm not making any promises for release dates.
That was in response to a different question, different issue. |
In which case all users who run latest composer will run into Is there any way to resolve that easily? Thank you! |
@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 |
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 |
As the values of the |
To apply this flag in a <!--
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 & ~E_DEPRECATED" /> (Note that the |
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.
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.
* 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]>
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. |
I am getting the same error. |
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 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!!! |
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 |
Still getting the same error on my MacBook with php 8.2. |
Working solution on m2 pro and PHP 8.1 |
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. |
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. |
If you haven't yet got a 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 |
@tuberb There is absolutely no need to use the |
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:
... 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
Additional Context (optional)
Tested Against
develop
branch?develop
branch of WPCS.The text was updated successfully, but these errors were encountered: