Comments (15)
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 likefunctions.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.
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.
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.
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.
If it's going to be flagged, maybe Error is too severe.
from wpthemereview.
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.
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.
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.
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.
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.
@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.
Oh, I haven't taken that into the account. Reopening and adding the necessary label 🙂
from wpthemereview.
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.
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.
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)
- Exceptions to prefixing hook names HOT 7
- False positive on loading stylesheet in JS file HOT 4
- [New sniff] WC template versions HOT 7
- Dealing with rules that shouldn't apply to templates HOT 1
- Add sniff: WordPress.PHP.IniSet HOT 6
- [New sniff] Check if page templates are using reserved prefix HOT 1
- Detect WPTRT feature project versions HOT 3
- Add sniff documentation HOT 1
- Minimal PHP version HOT 11
- Whitelist wp_body_open function from PrefixAllGlobals sniff HOT 5
- sniff: plugin territory - action hook wp_edit_nav_menu_walker
- File name with reserved slug in subfolder HOT 11
- Optimisation and minor grammar fixes
- [Implement sniff] Warn about short ternary usage in themes HOT 9
- Internal.Exception -- function update_current_version() should be removed.
- [Update existing sniff] Allow register_block_style HOT 1
- Allow `add_menu_page` & `add_submenu_page` HOT 9
- twentyseventeen theme: posts with no date - but date is shown in similar posts HOT 1
- 👍
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from wpthemereview.