GithubHelp home page GithubHelp logo

Comments (15)

jrfnl avatar jrfnl commented on July 4, 2024 1

We can nitpick over whether the feature is happenstance or intentional, but that doesn't really matter

That's not nitpicking, that's basic understanding of the principles of how PHP works.

What matters is that the notice is incorrect by the TRT guidelines. The team neither recommends nor requires that such variables be prefixed. Therefore, I'd recommend we disable it for now.

  • The sniff was added based on a rule in the TRT guidelines - see the discussion in #129
  • The sniff is not active by default. It only becomes active when a prefix is passed to the PHPCS run.
  • The sniff itself should not be deactivated/disabled as it checks for the prefixing of all global constructs, not just variables.
    If anything, only the errorcode regarding the prefixing of global variables should be deactivated/disabled.
  • If so desired though, a better solution would be to extend the WPCS sniff, overload the method which deals with prefixing variables and bowing out early if a theme template file is detected.
    That way, a file like functions.php would still be examined for global variables being properly prefixed, while template files would not be.
    How to detect whether a file is a theme template file, is something which would need to be discussed. I imagine a whitelist of file names / file name patterns might work, but other ideas are welcome.

I'd like to suggest for this issue to be discussed in a TRT meeting, bearing the above input in mind.

from wpthemereview.

joyously avatar joyously commented on July 4, 2024 1

The sniff is not active by default. It only becomes active when a prefix is passed to the PHPCS run.

Using it with a prefix is the best way to use it for themes, and that means it gives errors for all the variables in a template file.

from wpthemereview.

joyously avatar joyously commented on July 4, 2024 1

I think the WP global variables should still be caught in template files, because that's how the template files work (all the query vars are declared as global where the template is loaded, so that the globals are available). Those global names should not be assigned to in the template file, just like anywhere else, and should get flagged GlobalVariablesOverride.
Using set_query_var to pass data to a template is fine, but the variable has to be prefixed, since it is becomes global.
So what's left are incidental variables used in the template file.

from wpthemereview.

jrfnl avatar jrfnl commented on July 4, 2024

The theme template files are supposed to be loaded with core functions.

That's the crux of it: "supposed to". However, there is no guarantee that that's the only way that these files will be loading - think: plugins doing funky stuff -, so it's always better to be safe and prefix the variables, than sorry.

from wpthemereview.

joyously avatar joyously commented on July 4, 2024

If it's going to be flagged, maybe Error is too severe.

from wpthemereview.

justintadlock avatar justintadlock commented on July 4, 2024

This is a problem. If there's no way of detecting whether the variable is global or skipping templates, I'd say we need to disable this for the time being. Otherwise, theme authors will have to whitelist or prefix every single variable used in a template.

Even a warning, I believe, will be a hindrance to the TRT's review process because it'd mean additional time checking false-positives. But, I could live with that as a middle ground.

Variables defined by a theme/plugin should start with the theme/plugin prefix.

This notice is also not worded correctly. The guideline related to this is more appropriately:

Global variables defined by a theme/plugin should start with the theme/plugin prefix.

from wpthemereview.

jrfnl avatar jrfnl commented on July 4, 2024

Just to be clear: the variables we are talking about here are declared as global variables based on the file alone.
It's only by the happenstance that the file is included from within a function call in some other file, that they become local to that function.

This notice is also not worded correctly

I concur this can do with improvement, but that's something for WPCS.

from wpthemereview.

justintadlock avatar justintadlock commented on July 4, 2024

We can nitpick over whether the feature is happenstance or intentional, but that doesn't really matter. Personally, I intentionally use this PHP feature to do some pretty cool stuff, like passing data to templates (though I don't generally assign variables in a template).

What matters is that the notice is incorrect by the TRT guidelines. The team neither recommends nor requires that such variables be prefixed. Therefore, I'd recommend we disable it for now.

from wpthemereview.

justintadlock avatar justintadlock commented on July 4, 2024

That's not nitpicking, that's basic understanding of the principles of how PHP works.

Which was my point. It simply works like this because that's how PHP works.

The sniff is not active by default. It only becomes active when a prefix is passed to the PHPCS run.

Then, this should be a non-issue as far as the TRT is concerned. I was given the impression that it was a default check. If it is not now nor is it planned to become one of the default checks, it's not a high priority.

The sniff itself should not be deactivated/disabled as it checks for the prefixing of all global constructs, not just variables.
If anything, only the errorcode regarding the prefixing of global variables should be deactivated/disabled.

That's what I was asking for--that we disable the prefixing of global variables part.

from wpthemereview.

dingo-d avatar dingo-d commented on July 4, 2024

A sniff for this has been merged and will be in the next release (0.2.0). I'll close this to clean up the issues a bit.

from wpthemereview.

jrfnl avatar jrfnl commented on July 4, 2024

@dingo-d The fix which was merged addresses the PrefixAllGlobals part of the issue only.
Should this issue stay open to further discuss whether or not to address the GlobalVariablesOverride part of it as well ?

from wpthemereview.

dingo-d avatar dingo-d commented on July 4, 2024

Oh, I haven't taken that into the account. Reopening and adding the necessary label 🙂

from wpthemereview.

dingo-d avatar dingo-d commented on July 4, 2024

Ok, the GlobalVariablesOverride sniff will work in the templates (we didn't touch that), so I guess we're good on that front.

So what's left are incidental variables used in the template file.

What would be an example of an incidental variable?

from wpthemereview.

joyously avatar joyously commented on July 4, 2024

I don't see how you would distinguish between a variable that was set using set_query_var, which becomes global and needs a prefix, and other variables that are used as temporary (as if in a function, because that's the context) and are not global and don't need a prefix.
I suppose if it's a template file, it could be a Warning, and if not, it could be an Error.

from wpthemereview.

dingo-d avatar dingo-d commented on July 4, 2024

A discussion from the triage basically is in agreement with the comment by Juliette:

If so desired though, a better solution would be to extend the WPCS sniff, overload the method which deals with prefixing variables and bowing out early if a theme template file is detected.
That way, a file like functions.php would still be examined for global variables being properly prefixed, while template files would not be.
How to detect whether a file is a theme template file, is something which would need to be discussed. I imagine a whitelist of file names / file name patterns might work, but other ideas are welcome.

Also, a comment by @joyously was:

For template parts (non-standard names), yes -- they should not have to be prefixed.
For template files with standard names (header, footer, etc.), yes -- they should have to be prefixed.
For page templates, (no standard names), no -- they should have to be prefixed.

We still don't have the pattern that should be checked, so we need to work on this.

from wpthemereview.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.