Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Add sniffs for the theme checks #578
I am opening this issue after discussing this with @GaryJones, @westonruter, @fklein-lu, @jrf & @Rarst at the WCEU contributors day and showing this to the theme review admins and @samuelsidler before publishing. This is one part of the project to improve the theme review process.
We'd need two new rulesets:
A number of these sniffs are not - like a typical sniff - valid for each file, but need to sniff if something is sone at least once in any of the files. So we might need to add a wrapper for those particular sniff in the Theme Check bootstrap to run those against each file and only report if a positive/negative results was returned for all.
Rules which can probably be turned into a sniff:
Rules which can probably be turned into a sniff but would need to be run against every file before a positive/negative result can be determined:
Rules which would need another solution (like in the bootstrap file which would run PHPCS from the Theme-check plugin within an install):
We'd also want to check against either of these two functions:
Progress has been very slow over the past year (and a half), but should speed up significantly over the next few weeks as @dingo-d intends to have a working prototype of the new ThemeCheck plugin which would use the WPTRT-CS ruleset ready for WCEU.
Looking back over how development has flowed so far, generally speaking, any sniffs which were created for WPTRT-CS which would benefit the wider WP community - not just the TRT - have been pulled here in WPCS and included in WPTRT-CS via the ruleset.
Some more will be added in the near future, but they will be along the same lines.
All these sniffs - with
The original idea was that the WPTRT-CS would be a fork in the development phase, but would merge back into WPCS once the majority of development was done. This is how things are still currently set up.
But merging WPTRT-CS back into WPCS would introduce these theme specific sniffs into the
As the new theme sniffer would use Composer anyway, the WPTRT-CS repo could be transformed to be a new standard in its own right (like the VIP repo), which would pull PHPCS and WPCS in as dependencies and can use the WPCS (and PHPCS) sniffs by referencing them in the ruleset.
This will also create more clarity for maintenance of the WPTRT-CS repo as it can be unclear now for contributors when something needs to be pulled here in WPCS and when something needs to be pulled to WPTRT-CS.
So, @dingo-d and me would like to hear some opinions, please vote for either of these options:
Your input is appreciated!
I'm 100% behind number 3.
Just as WPCS builds on top of (has a dependency on) PHPCS by using some sniffs from it and including our own, for the benefit of the WP subsection of the PHP community, so should WPTRT-CS build on top of (have a dependency on) WPCS by using some of our sniffs and including their own, for the benefit of the TRT (and theme builders) subsection of the WP community.
What sort of sniffs do we need for
FYI: the split off of the Theme Review repo from WPCS has been finalized.
The Theme Review CS repo can now be found here: https://github.com/WPTRT/WPThemeReview
Any work which was originally contained in WPCS and remains in TRTCS (most notably three WPCS deprecated sniffs, but also some dev files) has been cherrypicked to the new WPThemeReview
A number of the open items mentioned in the original issue + in the comments have not (yet) been turned into issues in the TRTCS repo. If anyone from the TRT fancies doing so, it would be very helpful and very welcome indeed!