-
-
Notifications
You must be signed in to change notification settings - Fork 493
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add sniffs for the theme checks #578
Comments
We'd also want to check against either of these two functions:
|
FYI:
|
I SOLVE YOUR PROBLEM I HAVE DONE SAME WORK IN PAST |
@manishsaini1126 that reads a bit spammy, could you please clarify if you genuinely want to get involved with this. :) |
can you please briefly describe your problem |
The topic is described in great detail in the opening post. |
Hi all, I've had a discussion with @dingo-d today about the future of this ticket and the WPTRT-CS repo. 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 So.... 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! /cc @grappler @WordPress-Coding-Standards/wpcs-admins |
@Rarst can we discs now and sorry me not reply your msg |
FYI: I've re-ordered the list of sniffable rules into "Done" and "To do" to get a better overview of where this project is at. |
I would be OK with option 1, but number 3 may make the most sense at this point. |
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. |
Number 3 :) Also, I would like to see some sniffs for:
|
@acosmin Would you mind checking if there are issues open for the two sniffs you mention in the TRT fork repo ? If not, could you open issues for this there ? |
What sort of sniffs do we need for |
@justintadlock @acosmin Please have the discussion about |
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! |
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.
Action plan:
develop
branch, set up TC to use PHPCS and WPCS for at least part of the checks and start working on a deploy script which pulls in the dependencies via composer.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:
get_role()
,current_user_can()
,current_user_can_for_blog()
,user_can()
,add_..._page()
. [New Sniff] Check that capabilities are used not roles WPTT/WPThemeReview#27 / PR: Use capabilities not roles WPTT/WPThemeReview#36add_theme_page()
is used. Otheradd_..._page()
functions not allowed. [New Sniff] Check for adding admin page other than throughadd_theme_page()
WPTT/WPThemeReview#11 / PR: Add sniff to check foradd_..._page()
functions + unit tests. WPTT/WPThemeReview#13show_admin_bar( false )
is called or ifadd_filter( 'show_admin_bar', '__return_false' )
is somewhere in the code. [New sniff] No disabling of the admin toolbar. WPTT/WPThemeReview#1remove_action( 'wp_head', '_admin_bar_bump_cb' );
display: none
CSS identifiers:#wpadmin
and.show-admin-bar
These last two are suggested as warning as they will be less precise and need manual verification.
eval()
,ini_set
,popen()
,proc_open
,exec()
,shell_exec()
,system()
,passthru()
,base64_decode()
,base64_encode
,uudecode()
,str_rot13()
. List need proper review when creating the sniff (also look at the original regexes in the Theme Check plugin) [New Sniff] Forbidden functions WPTT/WPThemeReview#9 / PR: Add Theme forbidden PHP functions sniff + unit tests. WPTT/WPThemeReview#10This can probably be an extended class of one of the related checks like
WordPress.PHP.DiscouragedFunctions
orGeneric.PHP.ForbiddenFunctions
.cx=[0-9]{21}:[a-z0-9]{10}
orpub-[0-9]{16}
[Implement sniff] Disallow advertising/tracking codes WPTT/WPThemeReview#125For details, see https://github.com/Otto42/theme-check/pull/162/files
We could probably extend an existing sniff of similar ilk for this.
->add_setting()
for the Customizer include asanitize_callback
or asanitize_js_callback
parameter and that it's non-empty.An exception will need to be made for the (two) calls found in
Kirki_Settings
as they do correctly comply, but are wrappers for the real call. Check Customizer sanitize-callback is not empty WPTT/WPThemeReview#68 / PR: No Sanitize Callback WPTT/WPThemeReview#76For details, see Theme-Check plugin - /checks/deprecated.php Add sniffs for deprecated WP features #576 / PR: Modularizing the discouraged functions #633
We could probably extend an existing sniff of similar ilk for this.
How many versions back will need to be checked with the theme review board and might actually need to be challenged as the current 2/3 versions is based on when WP was only updated approx once a year from what I gather.
For details, see Theme-Check plugin - /checks/dep_recommended.php
We could probably extend an existing sniff of similar ilk for this.
wp_deregister_script()
isn't called. [New sniff] Verify that wp_deregister_script() isn't called WPTT/WPThemeReview#21 / PR: Add rule to prevent deregistering scripts. WPTT/WPThemeReview#26This is basically meant to only check that core scripts aren't being deregistered, however maintaining a list of core scripts for that purpose would be a maintenance nightmare, so returning a warning when any such call is encountered is the current solution.
Discussion needed in the Theme review board on whether this lists needs to be expanded with other generators and if so, which. Verify that the theme is not auto-generated WPTT/WPThemeReview#63 / PR: No Auto Generated Themes WPTT/WPThemeReview#65
<iframe
s (often used for malicious code). [New sniff] Check for the use of iframes WPTT/WPThemeReview#22 / PR: Feature/discouraged iframe WPTT/WPThemeReview#109include(_once)
orrequire(_once)
(where they should useget_template_part()
). Warning for using include and require WPTT/WPThemeReview#66 / PR: Warning for using include or require WPTT/WPThemeReview#67Current implementation excluded the
functions.php
file from this check. We may want to continue doing so.Generic.Files.LineEndings
should be sufficient for this. [Implement sniff] Have either UNIX or DOS line endings for PHP, JS and CSS files WPTT/WPThemeReview#3 / PR: Add rule to only allow UNIX style line endings. WPTT/WPThemeReview#7 Mark mixed line endings as error WPTT/WPThemeReview#90An exception is made for the Author URI and (Theme) URI as set in the style.css header as well as links to wordpress.org. [New Sniff] Check for hardcoded URLs WPTT/WPThemeReview#14 / PR: Check for Hardcoded Urls WPTT/WPThemeReview#28
Links in the text of PHP/JS comments should be excluded from this check.
For a list of functions to trigger on, see Theme-Check plugin - /checks/malware.php
For details, see Theme-Check plugin - /checks/more_deprecated.php
We could probably extend an existing sniff of similar ilk for this or even combine this with the other deprecated checks.
(register|wp)_nav_menu()
function, the theme should only use a variable for the menu name. No hard-coded menu names allowed. [New sniff] No hard-coded menu names in nav_menu functions WPTT/WPThemeReview#93[\x00-\x08\x0B-\x0C\x0E-\x1F\x80-\xFF]
. Quite possibly there will be an existing sniff somewhere we could re-use for this. [New sniff?] Check for non-printable characters WPTT/WPThemeReview#94Generic.PHP.DisallowShortOpenTag
sniff. [Implement sniff] No PHP short tags WPTT/WPThemeReview#2 / PR: Add rule to disallow PHP short open tags. WPTT/WPThemeReview#6Check if there is an existing sniff for the alternative opening tags, if not, I'd suggest opening a PR upstream at PHPCS to cover this in a separate sniff in
Generic
or add to extend the above mentioned sniff to cover this.Extend the existing
Generic.PHP.DisallowShortOpenTag
sniff to an XML specific one. [New sniff] No short open tags in XML WPTT/WPThemeReview#95register_post_type()
,register_taxonomy()
,add_shortcode()
. Check for functions that are plugin territory WPTT/WPThemeReview#73 / PR: Plugin Territory Functions WPTT/WPThemeReview#81Review this list with the Theme Review board as there might be some more functions which could be added.
The sniff could probably just extend the Forbidden Functions sniff - though it should be kept as a separate sniff for clarity.
searchform.php
are found, if they are, recommend usingget_search_form()
instead. Check for direct load of searchform.php WPTT/WPThemeReview#74 / PR: Direct including of template files WPTT/WPThemeReview#82style.css
whether the required headers are found. See Theme-Check plugin - /checks/style_needed.php for the list.style.css
whether the two recommended headers are found. See Theme-Check plugin - /checks/style_suggested.php for the list.Tags
in thestyle.css
file header comply with the current guidelines (allowed tags, deprecated tags (=> WARNING) etc). See Theme-Check plugin - /checks/style_tags.php for the list.style.css
file header tag list and add a warning that an accessibility review is needed. [New sniff] Check for the accessibility-ready tag WPTT/WPThemeReview#24For details, see Theme-Check plugin - /checks/time_date.php
<title..
isn't used except for in inlineSVG
code. [New sniff] Check for <title> WPTT/WPThemeReview#25 / PR: Add sniff to check that <title> tags are not used. WPTT/WPThemeReview#41wp_title()
. [New sniff?] No calls to wp_title() WPTT/WPThemeReview#97style.css
for theAuthor URI
and ThemeURI
and verify that these are not the same.style.css
that the ThemeURI
does not point towordpress.org
(with predefined list of themes which are exempt and live under thewordpressdotorg
user or have a check based on Author name - see the current check in checks/uri.php).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:
add_theme_support()
call is made for any feature the theme has been tagged with from the following list:custom-background
,custom-header
,custom-menu
,featured-images/post-thumbnails
,post-formats
,custom-logo
comment_reply
string or rather any HTML identifiers needed for the JS script to work are present (need more info) (comments should always be supported by themes, enqueuing the script alone is not enough)paginate_comments_links()
,the_comments_navigation()
,the_comments_pagination()
,next_comments_link()
orprevious_comments_link()
$content_width
or within a function usingglobal $content_width; $content_width =...
or$GLOBALS['content_width']
.Note: currently the Theme Check plugin also checks for filters on
embed_defaults
andcontent_width
and passes if those are found. Those checks are outdated and should not be ported.add_editor_style()
call is made if the theme has been tagged witheditor-style
.get_avatar()
orwp_list_comments()
is used at least once.(register|wp)_nav_menu()
is used at least once.This should become an error if the theme is tagged with
custom-menu
.(get_post_format()|has_format()
or CSS rules covering.format
are found, at least once if the theme has aadd_theme_support( 'post-format' )
call.This should become an error if the theme is tagged with
post-formats
.posts_nav_link()
,paginate_links()
,the_posts_navigation()
,the_posts_pagination()
,next_posts_link()
orprevious_posts_link()
the_post_thumbnail()
is found at least once if the theme has aadd_theme_support( 'post-thumbnails' )
call.This should become an error if the theme is tagged with
featured-image
.the_tags()
,get_the_tag_list()
,get_the_term_list()
add_theme_support( 'title-tag' )
is used in at least one file.register_sidebar()
ordynamic_sidebar()
is made.register_sidebar()
is found, make sure there is at least one call todynamic_sidebar()
as well and visa versa.register_sidebar()
function is called with anadd_action( 'widget_init', ... )
call.Rules which would need another solution (like in the bootstrap file which would run PHPCS from the Theme-check plugin within an install):
add_theme_support()
..git
,.svn
,.hg
,.bzr
. These should not exist in the repo.Exact list of exclusions should be re-determined in conjunction with the theme review board. This should include both system as well as development related directories.
thumbs.db
,.DS_Store
, travis config, PHPCS config.zip
files etc. For a list, see Theme-Check plugin - /checks/filenames.php. These should not exist in the repo. Zips are often plugin files and are not allowed to be shipped with a theme either.Exact list of exclusions should be re-determined in conjunction with the theme review board. Again, this should include both system as well as development related files.
index.php
andstyle.css
.readme.txt
file exists.The text-domain should also be in the
style.css
file header and again be consistent.The text was updated successfully, but these errors were encountered: