wordpress / theme-check Goto Github PK

Notice: Undefined variable: domain in /var/www/staging.dev/public_html/wp-content/plugins/theme-check/checks/textdomain.php on line 97

In line 97:
$token = $found_domain? ')' : ", '$domain')";

Checked theme: Twenty Fifteen
OS: Ubuntu 14.04

Should we keep in the custom header and background checks as those aren't required? I'm thinking making those go as not all themes have to have is a good idea in light of what themes have in now?

File main.php has an error message
"If you have found a bug or would like to make a suggestion or contribution why not join the theme-reviewers mailing list or leave a post on the WordPress forums.', 'theme-check' ); ?>

I may have missed something but to my knowledge, the theme-reviewers mailing list has been closed?

Tested Raindrops theme 1.276

https://wordpress.org/themes/raindrops/

In this theme, error of tag will occur when the theme check

I'm checked it why saying wrong message.

style_tags.php

foreach( $css_files as $cssfile => $content ) {
            if ( basename( $cssfile ) === 'style.css' ) {
                $data = get_theme_data_from_contents( $content );           
                break;
            }       
        }

add break, fine for me.

when Tags is blank

theme check say 'Found wrong tag, remove %1$s from your style.css header.'

} elseif( !empty( $tag) ) {

change from else to elseif( empty check ).

I think better

Is this a plug-in bug?

I am working on the German translation of the Theme Check plugin and stumbled upon two text strings that seem illogical for me:

• Screenshot size should be 880x660, to account for HiDPI displays. Any 4:3 image size is acceptable, but 880x660 is preferred.
• Screenshot is wrong size! Detected: %1$sx%2$spx. * Maximum allowed size is 880x660px.*

If ANY size is acceptable, it doesn't make sense to have a warning about a "Maximum allowed size".

Per this: REQUIRED: Sidebars need to be registered in a custom function hooked to the widgets_init action. See: register_sidebar().

Well, my widget_init, which handles the register_sidebar is inside a class, the action hook set in the constructor. theme-check doesn't see this. Maybe it should. Some of us prefer to use classes vs. loose functions and would prefer to not have to explain to themeforest a million times over the function is actually there and valid, but theme check just refuses to see it.

The checks using regex ain't great. For some checks like the recent text domain checks, the tokenizer was used. This can be made more generalized, to allow the tokenizer data to be only made once and then given to several checks.

This is a general issue to track the idea of using the tokenizer in multiple checks, and having the actual token process in the main check system instead of in each check.

Checks for wp_footer() and wp_head() can throw a false negative if there is a space between the word and first parenthesis.

Both wp_head () and wp_footer() will generate:

REQUIRED: Could not find wp_head. See: wp_head
 <?php wp_head(); ?>
REQUIRED: Could not find wp_footer. See: wp_footer
 <?php wp_footer(); ?>

With the new favicon feature in WP 4.3, we need to add an info notice if we spot favicons. I haven't completely looked into what all core does, but I believe it adds other icons as well. Not sure right off the top of my head what this check needs to look like.

Themes should only add this feature if < 4.3, so it should be an info notice.

I'm busy cleaning up the checks and noticed that the class names aren't prefixed, which could potentially break the theme if it has an own class with the same name. I know that theme check gets used mainly by the theme review team, but if a theme should have a class with the same name, the plugin can't be used.

Shall I prefix them all with TC_ or something else?

Just ran across this in a review:

//move jquery to the footer 
wp_deregister_script('jquery');  
wp_register_script('jquery', get_template_directory_uri() . '/js/vendor/jquery.js', false, '1.11.3', false); 

I read your thoughts on using wp_filesystem http://ottopress.com/2011/tutorial-using-the-wp_filesystem/

The reason I ask is some frameworks use it to load a json file. e.g. https://github.com/aristath/kirki/blob/master/includes/Fonts/FontRegistry.php#L256

As it is only reading and not writing a file do we have the same security risks?

Could we allow file_get_contents() in themes?

Theme URI and Author URI cannot be the same, which comes to..

users can bypass this if use a "/" at the end of a uri.

theme uri: http://www.domainname.com
author uri: http://www.domainname.com/

Hi,

My theme uses a custom made pagebuilder. All elements have their own folder and it includes a style.css file for that specific element. The check shows a false positive on "Tags: is either empty or missing in style.css header." due to this.

From what i see in the check file, there is a loop made trough all the css files present in the theme. Can this be changed to only parse the style.css file found in the root directory of the theme?

Best regards,
Stefan

When same text domain is used but apostrophe is different TC is displaying them as different.
Example:
INFO: More than one text-domain is being used in this theme. This means the theme will not be compatible with WordPress.org language packs. The domains found are 'modality',"modality"

One more way how to bypass the same URL.

Theme URL - http://www.example.com
Author URL - http://example.com

Related #56

https://wordpress.org/support/topic/add_setting-check-can-fail-even-if-callback-specified

Example to trigger:

$wp_customize->add_setting('foofoo', array(
  'foo'=>'string containing ; here',
  'sanitize_callback'=>'bar'
) );

Workaround for now: move the string into a variable outside the function call:

$str = 'string containing ; here';
$wp_customize->add_setting('foofoo', array(
  'foo'=>$str,
  'sanitize_callback'=>'bar'
) );

Fix: Regex in customizer.php check needs to be more robust.

enhance request.

tested with Raindrops theme.

https://wordpress.org/themes/raindrops/

Line 6431: if ( preg_match_all( '/(https?:\/\/)([-_.!��*\'()a-zA-Z0-9;\/?:@&=+$,%#]+)/iu', $text, $matches, PREG_SET_ORDER ) ) {
Line 8097: return preg_replace_callback( '|>([-_.!��*\'()a-zA-Z0-9;\/?:@&=+$,%#]{30,})<|', 'raindrops_add_wbr_content_long_te

I'm　using tilde in regex.

If, I want you to tolerate possible tilde

Thank you.

Hi,

My theme includes an xml export file. This export has tags like <title>.

The plugins shows a false positive because of this ( " The <title> tags can only contain a call to wp_title(). Use the wp_title filter to modify the output" ).

Can this check be limited only to PHP files ?

Best regards,
Stefan

Reported here:
https://wordpress.org/support/topic/bug-i-guess?replies=2#post-6175594

Example:
_e( 'text field (you can leave it blank', 'mytheme' );

Likely solution: tokenize the whole file instead of just that line. Similar to the patch for this:
#1

Hi Samuael!

In the file checks/basic.php line 14 is the url of codex.wordpress.org present twice.

In checks/include.php line 19 is %1$s %2$s %3$s
In checks/searchform.php line16 is %1$s %2$s%3$s
Missing since possibly a whitespace?

Greetings

Theme Check output:
REQUIRED: Found a Customizer setting that did not have a sanitization callback function. Every call to the add_setting() method needs to have a sanitization callback function passed.

Normally, this would be accurate. Adding sanitize_callback to $wp_customize->add_setting() is required, when using the default option type, theme_mod.

However, when using 'type' => 'option', with a valid sanitize_callback added to the register_setting() call, the sanitize_callback is not required in $wp_customize->add_setting().

Solution: check for sanitize_callback in the correct location:

1. If 'type' => 'theme_mod', then use the current check
2. If 'type' => 'option', then check for register_setting() call, and check for third parameter, 'sanitize_callback'.

We have removed the requirement for comments.php to be in themes. Do checks also need to be removed such as comment pagination and tags?

The full error also says curl_exec & curl_init were found, which is false.

Will this be a blocker? Let me explain. Redux uses these items are primarily fallback for when the WP_Filesystem fails. And oh yes, it does fail on odd hosts. We found that by doing this, we've reduced nearly 90% of permission error requests, and everything still works as expected.

We try the FileSystem API first, but then do this if it fails. Here's the code: https://github.com/reduxframework/redux-framework/blob/master/ReduxCore/inc/class.redux_filesystem.php#L160-L166

Any chance we can get "white-flagged" or find a way to allow this as a fallback?

According to this post from 4.3 in the admin side all page title will be in h1 tag. https://make.wordpress.org/accessibility/2015/07/08/accessibility-team-meeting-july-6-2015/

Accessibility team has recommended to change similar for all plugins which use settings page. May be we should also change it.

This was brought to my attention from a theme author. The TRT guidelines currently allow shortcodes. However, those shortcodes should not be intended for use in the post content. Currently, Theme Check makes this a warning, so themes with any shortcode (regardless of their uses) can't get past the uploader on WordPress.org.

Right now, this should be an "info" rather than a "warning" until the guidelines are changed to ban all shortcodes.

REQUIRED: plugins/class-tgm-plugin-activation.php. Themes should use add_theme_page() for adding admin pages.

        protected function add_admin_menu( array $args ) {
            if ( has_filter( 'tgmpa_admin_menu_use_add_theme_page' ) ) {
                _deprecated_function( 'The "tgmpa_admin_menu_use_add_theme_page" filter', '2.5.0', esc_html__( 'Set the parent_slug config variable instead.', 'raindrops' ) );
            }

            if ( 'themes.php' === $this->parent_slug ) {
                $this->page_hook = call_user_func( 'add_theme_page', $args['page_title'], $args['menu_title'], $args['capability'], $args['menu_slug'], $args['function'] );
            } else {
                $this->page_hook = call_user_func( 'add_submenu_page', $args['parent_slug'], $args['page_title'], $args['menu_title'], $args['capability'], $args['menu_slug'], $args['function'] );
            }
        }

This function, but I think there is no problem if want to use the theme,

Requid has occurs.

I should delete unnecessary code?

Thank you

Eg:

_e( 'Next page' )

I believe this is not allowed in theme.

What SHOULD we use to rid ourselves of that notice. :)

On a theme I was reviewing recently, I noticed TC wasn't picking up variable functions. Here's some code from the theme:

$post_type = 'register_post_type';

$post_type( 'post-type', $args );

And:

$encode = 'base64_encode';

$encode( $content );

Thanks for the new release.

Can you please update the pot file. Some translatable texts have changed. Thanks

Similar to #10 — new template tags in WP 4.1 aren't recognized.

From Twenty Fifteen Theme Check results:
REQUIRED: The theme doesn't have post pagination code in it. Use posts_nav_link() or paginate_links() or next_posts_link() and previous_posts_link() to add post pagination.

the_pagination() is used in the theme instead

A lot of developers use Grunt for automating tasks. It would be nice to warn that "node_modules" folder needs to be removed, but skip any checks inside since developers are likely just using this in development (and it takes a while if you forget to remove it).

I've noticed a strange behavior of the theme check of function.

for example. use twenty fifteen.

customize.php line 26

    $wp_customize->add_setting( 'color_scheme', array(
        'default'           => 'default',
        'sanitize_callback' => 'twentyfifteen_sanitize_color_scheme',
        'transport'         => 'postMessage',
    ) );

change below

    $wp_customize->add_setting( 'color_scheme', array(
        'default'           => 'default',
        'sanitize_callback' => 'twentyfifteen_abcdefg',
        'transport'         => 'postMessage',
    ) );

function twentyfifteen_abcdefg() , Such a function does not exist

but theme check plugin not say error.

WP_DEBUG not say error.

Theme works properly ... why?

Here's that list of updated deprecated functions. Not sure if you need all because some aren't really applicable to themes.

wp-includes:

// 4.3
wp_richedit_pre // Use format_for_editor()
wp_htmledit_pre // Use format_for_editor()

// 4.2
// Use 'customize_dynamic_setting_args' filter instead of these:
WP_Customize_Widgets::setup_widget_addition_previews()
WP_Customize_Widgets::prepreview_added_sidebars_widgets()
WP_Customize_Widgets::prepreview_added_widget_instance()
WP_Customize_Widgets::remove_prepreview_filters() 

// 4.1
WP_Customize_Image_Control::prepare_control()
WP_Customize_Image_Control::add_tab()
WP_Customize_Image_Control::remove_tab()
WP_Customize_Image_Control::print_tab_image()

// 4.0
get_all_category_ids()        // Use get_terms()
like_escape()                 // Use wpdb::esc_like()
url_is_accessable_via_ssl()
FORCE_SSL_LOGIN               // constant - Use force_ssl_admin( true ) ??

wp-admin

// 4.3
wp_ajax_wp_fullscreen_save_post()

The checks in customizer.php should give more information as to which line/setting the problem is found, in order to make it easier for authors to find missing sanitize callbacks.

INFO: More than one text-domain is being used in this theme. This means the theme will not be compatible with WordPress.org language packs.
The domains found are comicpress,comicpress

looked for comicpress,comicpress
looked for comicpress,
looked for ,comicpress

couldn't find anything but 'comicpress'

4.1 introduces a new title-tag theme feature. For backwards compatibility, the following is recommended:

if ( ! function_exists( '_wp_render_title_tag' ) ) :
function theme_slug_render_title() {
    echo '<title>' . wp_title( '|', false, 'right' ) . "</title>\n";
}
add_action( 'wp_head', 'theme_slug_render_title' );
endif;

This is throwing an error with the new title checks introduced in 9a6cbcb.

REQUIRED: The <title> tags can only contain a call to wp_title(). Use the wp_title filter to modify the output

Using just wp_title() in the recommended code prints immediately, instead of returning for the echo statement. This can be worked around using ob_start(), or splitting into three separate statements, but this seems like a round-about way to pass the test. Should the check be updated to allow false for wp_title()'s second attribute?

Now that WP 4.3 is out, title-tag should be a requirement rather than recommendation. This is was decided in the latest TRT meeting: https://wordpress.slack.com/archives/themereview/p1440526841000503

I'll see about putting together a PR.

The <title> element is an important accessibility feature for SVG images to provide accessible labels for those images. Current version of theme-check doesn't differentiate between a document <title> and an SVG <title>.

While I was reviewing a theme I found following in style.css.

Detect CDN import in style.css.

@import url(//maxcdn.bootstrapcdn.com/font-awesome/4.3.0/css/font-awesome.min.css);

This should be blocker I believe.

Also, may be it would be good to detect @import and recommend theme author to use proper hooks and functions to load styles and fonts.

@import url(http://fonts.googleapis.com/css?family=Arimo:400,400italic,700,700italic);

I encountered this Notice when start the check. After some minute firefox crash due to allowed memory. I'm using the latest master version.

Do we have a check for this? If not, can we add one into the theme check please?

Hi @Otto42
I just added a Polylang integration to my theme, but when I tested my theme with Theme Check, it display a translation info message because Polylang function pll__ contain __. Do you think you can add something like a function check to remove the info message if we integrate Polylang to our theme?

Thank you,
Satrya

If a class, namely Redux, possesses the ability to add_menu_page, but it is not used as a developer for .org, does it have to be flagged? I'd like this not to fail the forthcoming theme-check errors. ;)

Currently it fails theme check:

Automattic/_s#460

Automattic/_s@ce796e3

We need a required CSS check for .screen-reader-text. Just noting this in case someone wants to write a patch.

WARNING: Found PHP short tags in file ~/parsedown.php.

See: https://github.com/erusev/parsedown/blob/master/Parsedown.php#L758

Any way to fix this?

We don't need to flag ABSPATH use as a warning or required or even recommended. But highlighting it as something to take a look at, to ensure it is used correctly (or that something else isn't implemented incorrectly) would be helpful.

Something like: "Use of ABSPATH detected at [ref]. Verify that it is used appropriately."

Can we please change the following from recommended to required?

RECOMMENDED: Found the URL of a CDN in the code: netdna.bootstrapcdn.com/font-awesome. You should not load CSS or Javascript resources from a CDN, please bundle them with the theme.

We don't accept unless this was added via theme options and turned off by default. So far we had none, but it's optional.