Conversation
As things were, the determination of whether or not a `T_STRING` is a call to the global PHP native `str_replace()` function was severely flawed.
By switching the sniff over to be based on the WordPressCS `AbstractFunctionParameterSniff` class, this flaw is mitigated.
Includes adding a slew of additional tests, some of which (line 8 - 13, 28, 37, 45) are specific to the flaw being addressed in this commit.
Additionally, the tests have been made more comprehensive and varied by:
* Testing against false positives for calls to methods or namespaced function calls (= the issue being addressed in this PR).
* Testing against false positives for attribute class using the same name as the function.
* Ensure function import `use` statements are not flagged. We're not interested in those.
* Adding more variations to the pre-existing tests:
- Non-lowercase function call(s).
- Fully qualified function calls.
- Use PHP 7.3+ trailing comma's in a few function calls.
- Use both single quoted as well as double quoted text strings in the tests.
- Use other non-plain-text tokens in the passed parameter to test the `FileGetContentsUnknown` warning, which was previously untested.
- Multi-line function call.
- Comments in function call.
…nd PHP 8.0 named args Both are already handled correctly after the switch to the WordPressCS `AbstractFunctionParameterSniff` class.
…t class callables As first class callables will result in the function being called, but without us knowing the passed parameters, I believe it is appropriate to flag the use of `file_get_contents()` as a first class callable under the `FileGetContentsUnknown` warning. This commit implements this in a WPCS cross-version compatible manner. Prior to WPCS 3.2.0, first class callables would be send to the `process_no_parameters()` method. As of WPCS 3.2.0, they will be send to the dedicated `process_first_class_callable()` method.
… local file Unless people get really creative with ternaries and such, the use of `__DIR__` within the parameter basically means that we know they are retrieving a local file and we can silently ignore the function call. Includes test.
…ens in the parameter As things were, only the first text string token in the parameter was being examined, which resulted in false negatives. Includes test.
… parameters As things were, if the parameter did contain a text string token and that text string token did *not* contain the text "://", the sniff would stay silent, even when the parameter contained additional non-text string tokens, which means we cannot reliably determine whether it is a local file or not. This commit changes the order of the checks to _first_ check if any of the text string tokens in the parameter contain the "://" text. If so, it will throw the (more informative) `FileGetContentsRemoteFile` warning. If not, it will check if the parameter contained anything but text string related or empty tokens. If so, it will throw the (more generic) `FileGetContentsUnknown` warning. Includes test.
GaryJones
approved these changes
Jul 23, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Performance/FetchingRemoteData: extend AbstractFunctionParameterSniff
As things were, the determination of whether or not a
T_STRINGis a call to the global PHP nativestr_replace()function was severely flawed.By switching the sniff over to be based on the WordPressCS
AbstractFunctionParameterSniffclass, this flaw is mitigated.Includes adding a slew of additional tests, some of which (line 8 - 13, 28, 37, 45) are specific to the flaw being addressed in this commit.
Additionally, the tests have been made more comprehensive and varied by:
usestatements are not flagged. We're not interested in those.FileGetContentsUnknownwarning, which was previously untested.Performance/FetchingRemoteData: add tests for PHP 5.6 arg unpacking and PHP 8.0 named args
Both are already handled correctly after the switch to the WordPressCS
AbstractFunctionParameterSniffclass.Performance/FetchingRemoteData: add support for handling PHP 8.1 first class callables
As first class callables will result in the function being called, but without us knowing the passed parameters, I believe it is appropriate to flag the use of
file_get_contents()as a first class callable under theFileGetContentsUnknownwarning.This commit implements this in a WPCS cross-version compatible manner.
Prior to WPCS 3.2.0, first class callables would be send to the
process_no_parameters()method.As of WPCS 3.2.0, they will be send to the dedicated
process_first_class_callable()method.Performance/FetchingRemoteData: bug fix - recognize use of DIR as local file
Unless people get really creative with ternaries and such, the use of
__DIR__within the parameter basically means that we know they are retrieving a local file and we can silently ignore the function call.Includes test.
Performance/FetchingRemoteData: bug fix - examine all text string tokens in the parameter
As things were, only the first text string token in the parameter was being examined, which resulted in false negatives.
Includes test.
Performance/FetchingRemoteData: bug fix - false negative for compound parameters
As things were, if the parameter did contain a text string token and that text string token did not contain the text "://", the sniff would stay silent, even when the parameter contained additional non-text string tokens, which means we cannot reliably determine whether it is a local file or not.
This commit changes the order of the checks to first check if any of the text string tokens in the parameter contain the "://" text. If so, it will throw the (more informative)
FileGetContentsRemoteFilewarning.If not, it will check if the parameter contained anything but text string related or empty tokens. If so, it will throw the (more generic)
FileGetContentsUnknownwarning.Includes test.
Closes #531